FRICTIONLESS_NICOLE FORSGREN_ABI NODA **フリクションレスな開発者体験の実現** **AI時代における障壁を取り除き、価値を引き出し、競争を凌駕するための7つのステップ** **ニコール・フォースグレン、アビ・ノダ** --- **目次** - マーティン・ファウラーによる序文 - サラ・ドラズナーによる序文 - はじめに **第1部: 開発者体験を理解する** 1. 開発者体験とは何か？ 2. 開発者体験が重要な理由 3. フリクション：価値を損なう要因 **第2部: 開発者体験の3つの重要要素** 4. 開発者体験フレームワーク 5. フィードバックループ 6. フロー状態 7. 認知負荷 8. フレームワークを使ってフリクションを特定し、取り除く **第3部: ビジネスケースを作成する** 9. 開発者体験をビジネス価値に変換する 10. 自分の仕事を他者が関心を持つことに結びつける **第4部: 開発者体験の改善：7ステッププロセス** **ステップ1: 開発者体験の旅を始める** 11. 開発者にインタビューする 12. 学んだことを統合する 13. 開発者のワークフロー、ツール、フリクションを可視化する 14. ステークホルダーを理解する 15. 学んだことを共有する **ステップ2: 小さく始めて早期の成果を得る** 16. 適切なプロジェクトを選ぶ 17. 早期の成果を共有して勢いをつける 18. よくある落とし穴を避ける **ステップ3: データを活用して自分の開発者体験を最適化する** 19. データ基盤を確立する 20. 既に持っているデータを特定し活用する 21. アンケートを使って迅速な洞察を得る 22. 時間をかけてシステムメトリクスに投資する 23. 適切なデータをキャッチすることを確認する 24. データを実行可能な洞察に変える **ステップ4: 戦略と優先順位を決定する** 25. 開発者体験の取り組みに焦点を当てる 26. 開発者体験の優先順位を設定するための関連基準を使用する 27. 大局を見据える：クイックルーブリックを活用する **ステップ5: 戦略を売り込む** 28. ステークホルダー分析を活用して効果的にコミュニケーションを図る 29. 効果的なメッセージングにはカスタマイズと繰り返しが必要 **ステップ6: （あなたの）スケールで変化を推進する** 30. 自分の範囲に合わせてアプローチを適応させる 31. グローバルなコントロール範囲で変化を推進する 32. ローカルなコントロール範囲で変化を推進する 33. 中間的なコントロール範囲で変化を推進する **ステップ7: 進捗を評価し、価値を示す** 34. データを分析する 35. 結果を伝える準備をする 36. 進捗を共有する 37. 矛盾するメトリクスをナビゲートする 38. 学び、改善する 39. 評価は善循環の一歩に過ぎない **第5部: 開発者体験の進化と持続** **第一の実践: 開発者体験の取り組みにリソースを提供する** 40. 初期の取り組みを自力で立ち上げる 41. 専門の機能を構築する 42. 開発者体験の役割に必要な人材を育成する 43. 開発者体験を全員の仕事にする 44. 組織の異なる段階で予算を確保する 45. 開発者体験を定着させる **第二の実践: 変化を支える構造を作る** 46. 開発者体験の変化のためのフレームワーク 47. 変化の中でチームを支援する 48. 組織を変化に導く 49. 難しい仕事の中で自分を支える **第三の実践: 技術を持続可能で効果的にする** 50. プロダクトマインドセットを採用する 51. より良いソリューションを構築するためにプロダクトマネジメントの原則を使用する 52. 効率を高めるためにツールの標準化を活用する 53. 開発者体験の取り組みにおける技術的負債に対処する 54. すべてを統合する：持続可能な技術マインドセット 第4の実践 進化し、影響を拡大するデザインメトリクス 55 ステークホルダーのためのデザインメトリクス 56 メトリクスを使ってステークホルダーの問題を解決する 57 速さは競合に対して相対的である 58 シンプルに始めて、賢くスケールする 59 AIが必要なメトリクスをどのように変えるか（そして変えないか） 60 メトリクスを製品のように維持する 最終的な考察 61 何を待っているのですか？ 第6部 ワークブック 謝辞 著者について 序文 マーチン・ファウラーによる 私はシニアテクノロジーマネージャーたちとランチを共にしていて、そのうちの一人がソフトウェア開発チームを改善するための最新の取り組みを語っています。彼は、どのチームやスタッフが最も生産的かを教えてくれるメトリクスプログラムを立ち上げると言っています。それによって、彼は優秀な人材を昇進させ、最も劣る人を解雇しようとしているのです。これはプロフェッショナルな場なので、私は目を回さないように努めています。何とか言葉を挟もうと、彼がどのメトリクスを使っているのか尋ね、さらに彼の測定値とビジネスの成果を関連付けようとしているのか聞いてみます。しかし、残念ながら、彼を説得するのは難しく、まるで街灯の下ではなく茂みの中で鍵を探すようなものです。私が出会ったほとんどのエンジニアリングマネージャーはチームの生産性を向上させたいと思っていますが、出会ったほとんどの開発者は自分の仕事をより効果的に行いたいと考えています。しかし、こうしたランチは開発者を生産性についての皮肉に導くことが多く、単純な測定を行うことが、グッドハートの法則の持つ揺るぎない力を忘れさせるのです。「測定が目標になると、それはもはや良い測定ではない。」 しかし時折、魔法のような思考に陥らずに開発者の生産性を研究している人々に出会います。ニコールやアビのような人たちです。この本の鍵は、彼らが人々をより生産的にする方法を考えるのではなく、彼らを遅らせる*摩擦*の源を見つけることに焦点を当てている点です。摩擦とは、プルリクエストを提出してから数日間放置され、その間にコードを忘れてしまったり、単純なAPI呼び出しであるべきインフラを整えるのに2日間もかかってしまうことです。こうした摩擦のポイントを取り除くことが、開発者体験を改善し、ユーザーの手に有用なソフトウェアを迅速に届ける本質です。 彼らは、迅速なフィードバックを得ることで、私たちが正しい道を進んでいるかどうかを判断する方法を説明しています。私のスマホの地図上で青い点が動くまでの遅延が長ければ長いほど、間違った方向に歩く時間が長くなります。フィードバックが迅速であれば、私たちは流れの状態に留まり、スムーズに物事を進めることができ、製品やモチベーションを向上させることができます。流れは、私たちが何をすべきかを理解する能力にも依存しており、これは構造が不十分なコードや不安定なテスト、流れを妨げる中断などによって認知負荷に圧倒されないように注意する必要があることを意味します。開発者体験に焦点を当てることは、これらの三つの要素を妨げるものを見つけることです。開発者体験を改善することは、より良い成果をもたらします。 ビジネスにおける成果。インフラに手をこまねいて失った時間は、開発者の給与に無駄に使われたお金であり、ソフトウェアが本番環境に投入されるまでに時間がかかることで失われた収益でもあります。この本の大部分は、これらの摩擦点を見つけ出し、どの部分が最も問題を引き起こしているのかを特定し、それを修正するプログラムを開発する方法についてです。これには指標が関わりますが、それは開発者の体験をより深く理解するために使われます。コミット頻度は簡単に取得できるシンプルな数字ですが、それだけでは全体のストーリーの一部しか語れません。適切に選ばれた開発者へのアンケートは、しばしば無視されがちな視点を開き、開発者へのインタビューは数字に重要な文脈を加えます。これらを利益に結びつけるのは難しいですが、もしできれば、これらの指標はより効果的な運営へと導いてくれるでしょう。測定に関する私のお気に入りの言葉はグッドハートの法則ですが、最近気に入っているのはジェシカ・カーの言葉です。「不完全な測定は判断を誤らせる。」これは手がかりを見つけるためのガイドブックです。 マーチン・ファウラー チーフサイエンティスト、ThoughtWorks 前書き サラ・ドラズナー 「砂に考えることを教えるのは間違いだった」と、私は再び `rm -rf node_modules` を実行しながらつぶやきました。 promisingな新しいライブラリを試してみたかったのですが、その作者たちがAPIにのみ焦点を当て、エコシステムへの適合や依存関係の管理についてほとんど考えていないことがすぐに明らかになりました。これは珍しいことなのでしょうか？残念ながら、そうではありません。内部システムチームは、開発者の旅全体を無視することで、しばしば開発者を失望させたり、失ったりします。これこそが、ニコール・フォースグレンとアビ・ノダの著書『Frictionless』が非常に重要な理由です。提供物に対して思慮深いチームであっても、全体的な体験を見落とすことで、開発者の関心を失い、重要なビジネスを失う可能性があります。私たちが収集するデータ、提供する可観測性、フィードバックループ、テストなど、さまざまな要素が影響を与えます。私は自身のキャリアの多くをこの分野に没頭して過ごしてきました。開発者体験のVPとして、私は複数の機能を横断する組織を率いていました。分析チームが洞察を引き出し、開発者関係チームがフィードバックを集め、ドキュメンテーションチームが開発者を導き、重要なプラットフォームのギャップを埋めるエンジニアたちがいました。現在、私はGoogleのコアエンジニアリング組織を率いており、主要なGoogleアプリケーションを支えるWeb、Android、iOS、マルチプラットフォームのインフラを担当しています。これらの役割を通じて、ひとつの真実が明らかです。開発者は、摩擦や文脈の変化によって認知負荷を強いられ、システムの理解、デバッグ、タスクの完了、プロセスの遵守に支障をきたします。この負担は最終的にコードの品質や製品全体の体験に影響を与え、ひいてはそれが接続される製品にも影響を及ぼします。良好な開発者体験（DevEx）は重要です。なぜなら、それは採用と使用に直接影響を与えるからです。製品を楽しんで使う開発者は、その製品と共に成長し、推奨し、自分の組織内で擁護する可能性が高くなります。 DevEx（開発者体験）は単なる「あると良いもの」ではなく、どの開発者プラットフォームやツールの成功にとっても重要です。これまでの製品開発は、製品の単独機能を最大化することに焦点を当ててきました。しかし、開発者は製品を孤立して体験することはありません。もし私たちがDevExを真剣に考えるのであれば、他のツールと交差する機能を優先し、摩擦を最小限に抑える統合に投資する必要があります。従来の製品管理やソフトウェアエンジニアリングが開発者の旅を作り上げる上で重要な役割を果たすことは明らかですが、ユーザーが考慮しないかもしれない他の依存関係も存在します。コンパイラ、最適化ツール、ドキュメント、開発者の支援など、すべてが開発者の旅全体で連携して機能しなければなりません。 ニコール・フォースグレンは、開発者の生産性や組織の健康に関する厳密な洞察と有意義なデータを提供することで、業界で長年称賛されています。彼女は『Frictionless』の中でさらに一歩進み、著名なDevEx研究者であるアビ・ノダと提携し、開発者体験が本当に何を意味し、なぜ従来の役割や指標を超えて重要なのかを解き明かしています。彼らは、時には診断が難しいギャップを特定し、解消するための実践的なガイダンスや豊富なケーススタディを提供します。これにより、粗い部分を解消し、急性の痛点を軽減し、認知的負担を減らすことができます。技術と経営の橋渡しに長けた彼らは、利害関係者の賛同を得るための実践的な戦略も共有しており、これは意味のある変化をもたらすための重要な前提条件です。 ニコールとアビが示す多くのことは、私自身の経験と深く共鳴します。彼らの推奨事項は、自己報告の洞察からシステム生成データまで、定性的および定量的なアプローチを網羅しており、読者に具体的かつ実行可能な方法でDevExを改善するためのツールを提供します。彼らは、優先順位付けのための良いフレームワークや、実際の作業に対するルーブリックを使用する手助けをし、コントロールの範囲や目標に向けた実際の行動を取ることを含んでいます。開発者体験の改善に真剣な人にとって、『Frictionless』は欠かせない一冊です。 サラ・ドラズナー シニアディレクター、コアGoogleインフラストラクチャ --- 私たちがソフトウェアを構築する方法は常に進化しています。近年、継続的デリバリー、DevOps、アジャイルといった新しいアプローチが大きな期待を寄せられています。今日、AIはソフトウェアの構築方法を根本的に変えています。プロダクトマネージャーは数時間で動作するアプリケーションのプロトタイプを作成でき、開発者は自然言語の説明から全体のコードベースを生成できます。技術的でないチームメンバーも、わずか1年前にはエンジニアリングチームが数週間かけて作成していた機能的なツールを作成できるようになりました。 この前例のないコード生成のスピードにもかかわらず、多くの組織は顧客にソフトウェアを提供することが依然として非常に煩雑であると感じています。新しい競合が毎分のように現れ、顧客の期待は高まり続け、革新のプレッシャーはかつてないほど強まっています。ソフトウェア開発の非効率性のコストは非常に大きく、測定可能です。CISQの研究によると、技術的負債はアメリカで大きなコストを引き起こしています。 企業は毎年1.52兆ドルを技術的負債に費やしており、平均的な企業は360万ドルの技術的負債を抱えています。マッキンゼーの報告によれば、開発予算の最大40％が回避可能な再作業に使われているとのことです。一方で、開発者は平均して68.4％の生産性しか感じておらず、その欠けている31.6％は年間約3000億ドルのGDP損失に相当します。私たちは数百のソフトウェアチームと協力する中で、優れたパフォーマンスを発揮する組織を一貫して分ける要因を見つけました。それは「開発者体験（DevEx）」です。DevExが悪いと、どんなに優れた開発者でもその能力を発揮できません。 実際の組織でDevExを改善することは、技術的な課題だけでなく、リーダーシップの理解を得ることや、データと測定を活用して最も大きな機会を特定すること、そして組織全体でチームを複雑な変化に導くことなど、多くの挑戦を伴います。この本は、まさにそのための実践的なガイドです。AIの登場は、インターネット以来のソフトウェア開発における最も重要な変化かもしれませんが、開発者体験はこれまで以上に重要になっています。AIツールを迅速に展開しようとする企業は、これらのツールが開発者の生産性を向上させ、高品質なソフトウェアを構築するのに役立つことを理解する必要があります。 逆説的に、エージェント的な開発が進む中で、組織は投資の必要性を再認識しています。正しいプラットフォームやAIモデル、または自動化がすべてを解決する万能薬であると信じるのは簡単ですが、現実はもっと複雑です。AIや継続的デリバリーのような変革は巨大な可能性を秘めていますが、新たなリスクや作業方法も導入します。これらの変革に成功するためには、組織は投資が本当に開発者により良いソフトウェアを提供させることを可能にすることを確認する必要があります。 私たちは、ソフトウェア開発ライフサイクルにおける摩擦の原因を特定し、重要なことを測定し、デリバリーを加速させる持続可能な改善を行う方法を示します。これは、チームがAIツールを取り入れる場合でも、従来のワークフローを維持する場合でも同様です。このガイドは主に中規模から大規模な組織でDevExイニシアチブを推進するリーダー向けに書かれていますが、その教訓は小規模なチームにも同様に適用できます。また、私たちが共有するフレームワークや原則は、レガシーのメインフレームから最先端のAIワークフローまで、あらゆるソフトウェア開発の文脈で機能します。スタートアップがこれらのアプローチを用いて、より早くスケールし、燃え尽きを減らし、より良いソフトウェアを出荷する様子も見てきました。 次の章では、開発者体験を変革するために必要なすべての情報を提供します。理解から行動に至る完全な道筋を示します。第1部ではDevExの重要性を説明し、第2部ではそれを理解するためのフレームワークを提供し、第3部では改善のためのビジネスケースを作成する方法を示します。 第IV部では、実施のための7ステップの方法論を紹介します。摩擦点を特定し、影響を測定し、戦略を策定し、ステークホルダーにコミュニケーションを取り、進捗を評価し、ビジネスの価値を示すというプロセスです。第V部では、DevExの改善を持続させるための実践方法を共有します。全体を通して、実際の事例、成功とROIを測定するためのフレームワーク、そして取り組みを始めるための実用的なテンプレートやツールが見つかります。各章は前の章を基に構築され、DevExの改善のための完全なシステムを作り上げますが、この本は現在の課題に最も関連する部分に簡単に焦点を当てられるように特別に設計されています。多くの章には、付随するオンラインワークブックに追加の資料や演習が含まれています。テキストがこれらのリソースを指し示す際にはアイコンが表示されます。開発者体験は単なる気分を良くするアイデアではなく、ソフトウェアの構築方法を変革するための戦略的なレバーです。AIが開発ワークフローを再構築する世界では、DevExに投資する組織がより迅速に動き、より良いものを構築し、未来をリードすることになります。それでは始めましょう。 PART I | DevExの理解 開発者体験を理解することは、この本のすべての基盤です。DevExを改善したり、その影響を測定したり、組織のサポートを構築したりする前に、実際にそれが何を意味するのか、そしてなぜそれがビジネスの成功にとって非常に重要なのかを明確に理解する必要があります。特にAIがソフトウェアの構築方法を変革する中で。ここでは、摩擦の軽減という観点から開発者体験を定義し、それがなぜ重要な競争優位性となったのか、ソフトウェアの提供を遅らせる摩擦の種類を検討します。遅いビルドに苛立つ開発者、チームがより早く出荷できるように支援しようとするマネージャー、ビジネスやAIツールが要求するスピードでエンジニアリング組織が動いていない理由を考えるリーダーにとって、これらの章は問題を特定し、意味のある変化を促進するための概念的な基盤を提供します。 第1章 開発者体験とは何か？ 開発者体験は、開発者を幸せにすることだけではなく、ビジネス全体を遅らせる摩擦を取り除くことです。具体的には、開発者が数分でコードを生成できるようになると、DevExはさらに重要になります。なぜなら、AIが創造を加速させる一方で、チームはそのコードをスケールでテスト、デプロイ、維持するための堅牢なシステムを必要とするからです。ソフトウェア開発において開発者中心の視点を持つことで、革新、品質、生産性を妨げるボトルネックや摩擦を迅速に特定できます。市場の力がDevExをこれまで以上に重要にしています。市場の圧力の増加、システムの複雑さの増大、AIの能力の進展により、組織はユーザーや顧客にこれまで以上に迅速に価値を提供する必要があります。これがDevExの出番です。AIは、数分で動作するコードを生成し、非技術的な役割が機能的なプロトタイプを作成できるツールを使って、ソフトウェアの構築方法を再形成しています。 一方で、Alisはパッチ適用、移行、障害検出といった従来の開発タスクを自動化しています。この開発ライフサイクル全体にわたる変革は、優れた開発者体験の必要性を減少させるように思えるかもしれません。結局のところ、AIが創造やメンテナンスを担えるのであれば、開発者の摩擦を心配する必要はないのではないかと。しかし、実際はその逆です。AIが多くのタスクを加速させる一方で、チームはAIが生成した変更を検証し、自動化されたプロセスを調整し、ますます複雑化するワークフローを監視するための堅牢なシステムを必要としています。開発者向けAIの基本は、開発者体験がビジネスの成功に重要であることを認識するという長い物語の最新の章を表しています。開発者体験の概念は長年存在していましたが、DevExの要素や影響に関する研究は2000年代中頃から活発になりました。インターネットの普及やAmazonのような企業の成功は、ソフトウェア開発がもはや単なるサポート機能ではなく、ビジネス成功の中心であることを明らかにしました。この変化は、開発者の生産性をエンジニアリングの懸念から戦略的優先事項へと引き上げました。この注目の高まりには、さまざまな相互に関連する要因が寄与しています。 - クラウドインフラストラクチャやマイクロサービスの複雑さの増大は、新たな開発者の摩擦を生み出し、デプロイメントや運用のリスクを高めました。 - マーティン・ファウラーのような思想的リーダーの影響力が増し、より多くの開発者に可能性を示しました。 - 高度なツールを持つ企業（例えばGoogle）での経験を持つ開発者が、他の企業の慣行に疑問を持ち始めました。 - オープンソースの経験が向上し、期待が高まりました。 - 『The Phoenix Project』や『Accelerate』、SVPGの著作（『Inspired』や『Transformed』を含む）などの影響力のある書籍が、エンジニアリングチームを超えてビジネスリーダーに可視性をもたらしました。 - 追加の研究が、開発者の摩擦や生産性を体系的に解決するための証拠やフレームワークを提供しました。 これらの発展は、問題と機会の両方を明らかにしました。これらは、ソフトウェア開発における摩擦が生産性と革新の可能性を著しく制約していることを浮き彫りにしました。同時に、開発者体験を改善することで、かつてない速さでより多くの価値を提供できることを示しました。これは「開発者体験」についての話ですが、具体的に開発者とは誰を指すのでしょうか？私たちが開発者と呼ぶのは、ソフトウェアエンジニア、品質エンジニア、ビルド/リリースエンジニアなど、ソフトウェアの作成とデプロイに直接関与するコアビルダーの役割を指します。プロダクトマネージャーやデザイナー、その他の役割も開発プロセスにおいて重要ですが、彼らは異なる成果物を生み出し、DevExイニシアティブにはあまり適さない測定上の課題を抱えています。多くの企業はこれを認識し、それに応じて用語を適応させています。 - Amazonはすべての技術的役割を含む「ビルダー体験」と呼んでいます。 - Spotifyは、彼らの全技術組織を含む「R&D体験」を使用しています。 他の企業では「エンジニアリング体験」や「メイカー体験」といった用語が使われています。AIはソフトウェアの創造に参加できる人々を再定義しています。プロダクトマネージャー、デザイナー、ビジネスアナリストは、ますますAIツールを活用して実働するソフトウェアを生成しており、従来の役割の境界が曖昧になっています。この民主化は、機会をもたらす一方で、コードの品質、メンテナンス、システムアーキテクチャに関する新たな考慮事項も生じさせます。 第2章 開発者体験が重要な理由 開発者体験が悪いことは、単に生産性の問題ではありません。それは、目の前にある壊滅的なビジネスリスクを隠す可能性があります。2012年のある朝、ナイトキャピタルの開発者がルーチンのアップデートを行いました。何も問題はないように見えましたが、システムが急速に資金を失い始めました。わずか45分で、たった一つの変更が4億6000万ドルの損失を引き起こしました。その原因は、長い間使用されていなかった機能フラグが、デプロイメントスクリプトによって誤って再活性化されたことでした。しかし、本当の問題はバグではなく、問題を迅速に検出し修正することを不可能にする開発環境でした。これにより、ルーチンのミスが会社を終わらせるような大惨事に変わってしまったのです。ナイトキャピタルの開発者たちは、自動テストスイートなしで作業し、エラーが発生しやすい手動デプロイに依存し、問題を迅速にキャッチするための監視システムも持っていませんでした。 2025年7月に進むと、ジェイソン・レムキンは自社SaaStr.AlのためにReplitのAIコーディングアシスタントを使ってデータベースを構築していました。彼は明示的に「コードフリーズ」を設定し、ライブデータに変更を加えないようにしました。しかし、AIは彼の指示を無視し、彼の生産用データベース全体を削除してしまいました。この事件は開発者コミュニティに衝撃を与え、AIツールの安全性について緊急の疑問を呼び起こしました。興味深いことに、もしナイトキャピタルのリーダーシップに技術戦略について尋ねていたら、彼らは取引アルゴリズム、市場データ、またはシステムパフォーマンスについて話したかもしれません。もし事件の前にレムキンにAIコーディングツールについて尋ねていたら、彼は生産性の向上や開発速度に焦点を当てていたかもしれません（彼のツイートもこの感情を反映しています）。しかし、もし彼らの開発者やオペレーターに日々の体験について尋ねていたら、デプロイメントプロセスの摩擦、手動リリースの不安、ツールへの信頼についての話を聞くことができたでしょう。今日、AIが開発とデプロイメントのサイクルを加速させる中で、これらの摩擦点はさらに危険になります。コードをこれまで以上に迅速に生成しデプロイできるようになると、堅牢なテスト、監視、デプロイメントプロセスは単なる「あればいいもの」ではなく、AIによって引き起こされる災害に対する重要な防護策となります。 開発者体験の改善は、この視点の変化を認識することから始まります。「どうやってソフトウェアをもっと早く作るか？」ではなく、「ここでソフトウェアを作り出し、出荷することは実際にどのようなものか？」と問いかけます。その答えは、ビジネスがどこに脆弱性を抱えているかを明らかにし、全員を守るための解決策を指し示します。安全なデプロイメント、より良いツール、そしてツールと戦うのではなく革新に集中できる開発者たちです。ナイトキャピタルは生き残りませんでしたが、彼らの物語はなぜ開発者体験が重要であるかを示しています。 開発者の日常の経験は、生産性だけでなく、ビジネスの存続にも関わっています。ナイトキャピタルの物語は特異なものではなく、現代ビジネスの広範な現実を反映しています。ありきたりな表現かもしれませんが、今日のすべての企業はソフトウェア企業です。小売、銀行、製造、医療など、すべての業界が競争し、顧客にサービスを提供するためにソフトウェアに依存しています。AIは、組織全体でのソフトウェア作成の障壁を下げ、コードを書いたことのないチームが実用的なソリューションを構築できるようにしています。しかし、多くの組織は、開発プロセスにおける摩擦によって制約を受け、市場の要求に応じたペースでの提供ができない状況にあります。 現代の開発ワークフローには、あらゆるところに摩擦が存在します。これには、数日かかる煩雑なセットアップ手順、ボトルネックを生むセキュリティレビュー、予告なしに壊れる不安定なデプロイメントパイプライン、そしてさまざまなツールに散らばったドキュメントが含まれます。AIツールは、セットアップスクリプトの自動化やドキュメントからの回答の抽出など、一部の課題に対処する手助けができますが、新たな摩擦点も生み出します。AIツールへのアクセス管理、AI生成ソリューションの検証、AIワークフローと既存プロセスの統合などです。 錆びた自転車のチェーンのように、開発者体験が悪いとすべてに負担がかかります。バグ修正、機能の出荷、新しいアイデアの革新などです。開発者がこれらの持続的な障害を克服するためにエネルギーを費やしている間、難しい問題を解決したり、画期的なソリューションを生み出したりする余力はほとんど残りません。AIの加速は、既存の開発プロセスに新たな認知的課題をもたらします。AIツールを効果的に利用するためのプロンプトの学習、AI生成コードの検証、AI支援と従来のワークフロー間の常時切り替えの管理です。これらの中断は集中力を分散させ、精神的な負担を増加させるため、スムーズで摩擦のないプロセスがさらに重要になります。コードが早く書かれるほど、下流の摩擦を排除し、開発者の認知能力を高価値な作業に保つことが重要になります。 このボトルネックの変化が、可視性の重要性を高める理由です。開発パイプライン全体の健康状態を示す指標やデータが必要であり、摩擦を特定し、対処することで、AIへの投資を損なう前に生産性の向上を図ることができます。悪化した開発者体験は、時間とともに競争上の不利を生み出します。ソフトウェアの提供における摩擦は、実験や学習の能力を制限することで、機能開発と革新を同時に遅らせます。顧客が必要な機能や新しいソリューションを得られないと、これらの障壁を取り除いた競合他社が実験、革新、迅速な出荷を行い、市場で急速に先行することができます。AIがソフトウェア作成を民主化する時代において、これらの利点はさらに加速し、開発者体験が重要な競争差別化要因となります。 LinkedInがどのように摩擦を排除し、ビジネスを変革したのか。 2011年10月、LinkedInは表向きには90億ドルの成功を収めていましたが、裏ではエンジニアリングチームが多くの障害に悩まされていました。エンジニアたちは、ユーザー向けの機能を構築するのではなく、内部システムと格闘する日々を送っていました。その障害はあまりにも深刻で、LinkedInは新機能を月に1回しか展開できず、競合他社は毎日更新を行っていました。新たに就任したエンジニアリング担当VPのケビン・スコットは、思い切った決断を下しました。すべての機能開発を2ヶ月間凍結し、障害を取り除くことです。プロジェクト「InVersion」は、LinkedInの開発インフラをゼロから再構築し、すべてのエンジニアに迅速に動けるためのツールを提供するものでした。会社は途中で古いシステムを解体し、後戻りはできなくなりました。その結果は劇的でした。プロジェクト「InVersion」が完了して数週間以内に、LinkedInは月次の展開から1日に複数回のリリースへと移行しました。フラストレーションを抱え、他社に転職していたエンジニアたちは突然活気を取り戻し、壊れたツールと戦うのではなく、革新に時間を費やすようになりました。ビジネスの加速は即座に現れ、外部の観察者たちはLinkedInの製品が前例のない速さで改善されていることに気づきました。成長を静かに圧迫していた障害を取り除くことで、LinkedInはチームの潜在能力を最大限に引き出し、今後数年間の競争優位性を確保しました。 開発者体験（DevEx）には位置づけの問題があります。これは、良いDevExが実際に何を提供するかについての根本的な誤解から生じています。多くのリーダー（および一部のエンジニア）は、効率的で使いやすい開発ワークフローがどれほど変革的であるかを個人的に体験したことがないため、ビジネスへの影響を認識していません。そのため、DevExの取り組みが測定可能な投資収益をもたらすことを伝え、証拠をもって示すことが重要です。この本では、その主張をどのように行うかを具体的に示します。次の章では、DevExが納品速度、品質、ビジネス成果に与える影響を示す具体的な指標やフレームワークを探ります。 良い開発者体験は「幸せ」ではなく、障害を取り除くことに関するものです。DevExの改善は、開発者が価値を創造できるように、体系的に障害を取り除くことです。AIコーディングアシスタントや改善されたデプロイメントパイプラインなどのより良いツールはその一部ですが、明確なプロセス、迅速なフィードバックループ（迅速なテスト結果や即時のデプロイメントフィードバックなど）、そして認知負荷の軽減も重要です。開発者はコーディングをしたいと考えており、自分のコードが影響を与えることを望んでいます。しかし、彼らは自分のコードが信頼性を持って機能するという自信も求めています。これは、AIの時代において特に重要であり、迅速なコード生成が信頼性のないシステムや予測不可能な失敗のコストを増幅させます。ソフトウェアの作成、実験、安全な出荷を容易にすることで、ビジネスに対する価値の提供を加速させるだけでなく、そのプロセスは自己強化する勢いを生み出します。 より幸せで生産的な開発者は、意義のある開発に集中できるため、より多くのビジネス価値を生み出します。開発者にとっての本当の満足感は、優れた作業を支える環境の中で影響力のあるコードを書くことから得られます。迅速な価値提供と、ツールやプロセスにおける摩擦の軽減が、より幸せで生産的な開発者を生み出します。 優れた開発者体験を持つ組織は、決定的な競争優位を得ることができます。彼らの開発者は、ツールとの格闘ではなく、革新や問題解決に集中でき、時間を消費する（そして退屈な）反復作業を避け、安全で信頼性の高いソフトウェアを書くことができます。これにより、インシデントやバグが減少し、開発者は中断されることなく、優れた仕事を提供するために必要な集中力を維持できます。組織は、顧客やビジネスにより良くサービスを提供するソフトウェアソリューションの迅速な提供を通じて利益を得ます。 開発者体験（DevEx）とプラットフォームエンジニアリングは、異なるアプローチながら共通の目標を持っています。「開発者体験とプラットフォームエンジニアリングの違いは何ですか？」とよく質問されます。これらは密接に関連していますが、開発者の摩擦を解決するための異なるアプローチを表しています。プラットフォームエンジニアリングは、開発者が基盤として使用できる標準化されたインフラストラクチャ、ツール、サービスの作成に焦点を当てています。これは、ベストプラクティスを強制し、複雑さを抽象化する共有技術プラットフォームを構築することです（これは開発者体験を改善する方法の一つです）。プラットフォームチームは通常、これらのサービスを所有し、開発チームに内部製品として提供します。 一方、開発者体験は、開発ライフサイクル全体にわたる摩擦をより広い視点で捉えています。オンボーディングやコーディングからテスト、デプロイ、監視に至るまで、すべてを検討します。DevExの取り組みは、プラットフォームエンジニアリングの解決策を必要とする問題を特定することもありますが、プロセス、コミュニケーション、またはチームダイナミクスにおける摩擦点に対処することもできます。多くの組織が開発者体験を成功裏に改善する際には、これらのアプローチを組み合わせています。DevExの原則を用いて摩擦を特定し、プラットフォームエンジニアリングを共通の技術的障害を体系的に排除するための戦術の一つとして活用しています。 AIツールは、これらのアプローチの特に興味深い交差点を表しています。プラットフォームチームは標準化されたAI開発環境やモデルへのアクセスを提供する一方で、DevExの取り組みは、AI支援が開発者の日常のワークフローにどれだけシームレスに統合されるかに焦点を当てています。これにより、良循環が生まれます。プラットフォームエンジニアリングは、労力を軽減し、認知負荷やフィードバックループを改善するためのアーキテクチャ的解決策であり、DevExはより一般的で、広範な開発プロセスを最適化します。 多くの組織は、開発者体験の改善が価値提供の目標と競合すると誤解しています。彼らはそれをスピードや効率に対する気を散らすものや競合する利害と考えていますが、実際にはその逆です。 開発者体験は、力を倍増させる要素として機能します。エンジニアの価値を理解している企業は、彼らが効果的に仕事をするためのツールに投資し、迅速な価値提供とより良い顧客成果を実現します。DevExの改善は、快適さのためにスピードを落とすことではなく、加速を妨げる障害を取り除くことにあります。 第3章 摩擦：価値を奪うもの 摩擦は進捗を遅らせる要因であり、特にソフトウェア開発においてはその影響が大きいです。だからこそ、DevExの改善が重要なのです。現在、新しく雇われたソフトウェア開発者は、有望なテクノロジー企業での3週目を迎えていますが、まだデータベースへのアクセスを待っており、古いドキュメントを読み解いています。彼女の最初のプルリクエストにはAI生成のコードが含まれていましたが、誰がAI支援の作業をレビューするのか分からず、レビューが行われないまま数日が経過しています。AIの出力を検証するための明確なプロセスもなく、問題を迅速に見つけるためのAI搭載のコードレビューツールにもアクセスできません。ビルドパイプラインはランダムにクラッシュし、プラットフォームチームは「次のスプリントで修正する」と約束している既知の問題です。 開発者がようやく簡単な変更をデプロイしようとすると、それには3つのチーム間での手動調整が必要で、それぞれ異なる承認ワークフローが存在しますが、どれも新しいAIツールによってサポートされる迅速な反復サイクルには対応していません。障害を乗り越える時間が機能を構築する時間よりも多くなり、彼女はもっと良い働き方があるのではないかと考えます。摩擦とは、仕事を完了するのを遅らせたり妨げたりするすべての要素です。これは、不明瞭なプロセス、欠落したドキュメント、複雑なツールチェーン、自動化の欠如として現れます。そして、システム内の摩擦は、AIから得られる効率や生産性の向上を台無しにする可能性があります。 今日、摩擦は現代の開発の至る所に存在します。オンボーディングの遅延や脆弱なコードベース、遅いビルド、複雑なデプロイメントプロセスなどです。各摩擦点は、マーケットへの投入時間や競争力に影響を与える累積的な遅延を生み出します。AIが開発ワークフローを変革する中で、これらの摩擦点はさらに高価になります。なぜなら、コードをより早く生成できるチームが、効率的にデリバリーできない場合、AIへの投資は従来のボトルネックによって制約されるからです。 一般的に見られる摩擦のいくつかの領域には以下が含まれます： + オンボーディングの摩擦。新しい開発者は、不完全なドキュメントに苦しみ、システムアクセスの承認を待ち、直感的でないツールセットを学ぶために数日または数週間を費やし、ようやく生産的なコードの1行を書くことができます。経験豊富な開発者も、ラップトップの更新やシステムの再イメージングの際に同様の摩擦に直面し、アクティブなスプリント中に貴重な時間を失います。リモート開発者は、ドキュメントで答えを見つけるのに苦労し、助けを求めるためにはミーティングを設定しなければならないため、さらに困難です。 + コードベースの摩擦。不十分な抽象化が開発者を強いることで、彼らの作業が妨げられます。 多くの場所に手を触れ、簡単な変更を加えることが求められますが、脆弱で一枚岩のような構造物が時間とともに蓄積され、テストの拡張が難しくなります。また、かつてコードにとって有益だったパターンが、システムの進化に伴い障害となることもあります。統合の摩擦。誤設定されたAPIや互換性のないツールチェーンは、開発者の流れを妨げ、本来シームレスであるべき接続を、フラストレーションを伴う回避策や手作業に変えてしまいます。プロセスの摩擦。複数段階の承認プロセスや、何度も繰り返されるレビュー、官僚的な要件は、実際の開発作業を遅らせることがよくあります。この摩擦のコストは、プロセス要件が緩和され、革新が迅速に行われるハッカソンの際に明らかになります。レビューの摩擦。数時間で終わるはずのコードレビューが、非効率なPRの割り当てや不明確なコードやモジュールの所有権（特にモノレポ環境において）、不明確な要件による複数のレビューサイクル、大きく複雑なPR（孤立して作業している開発者による）によって、数日かかることがあります。開発の摩擦。非常に遅いビルド時間、信頼性のないテストスイート、完璧でないテストカバレッジ、実際の問題なしに断続的に失敗するフレークテストは、開発者の時間を浪費し、アクティブなコーディングセッション中の集中力を妨げます。デプロイメントの摩擦。ワンクリックでのデプロイではなく、開発者は自動化が不完全なため、コードプッシュごとにカスタムスクリプトを書くか、デプロイメントの決定を下すために異なるシステムから手動でデータを集めるのに数時間を費やします。これらの摩擦ポイントは、個々の開発者の作業を遅くするだけでなく、累積的な遅延やコンテキストスイッチを生み出し、企業の市場投入までの時間や競争力に大きな影響を与えます。開発者は時には待っている間に他のタスクに移ることができますが、これらの予測不可能な遅延は、彼らに複数の作業を同時にこなさせることになり、重要な問題に深く集中する能力を妨げます。このような継続的な中断は、生産性を損なうだけでなく、慢性的なストレスやフラストレーションを生み出し、燃え尽き症候群や離職につながります。このような断片的な注意と燃え尽きのリスクが数百人の開発者や数十のデプロイメントに広がると、毎年数ヶ月分の革新が失われることになります。これらの摩擦ポイントを排除することで、即座にビジネス価値が生まれます。各障壁を取り除くことで、数分の節約や開発者の集中力向上だけでなく、全体の革新サイクルを加速させることができます。オンボーディングの障害から解放されたチームは、数週間ではなく数日で貢献できるようになります。ツールチェーンの悪夢から解放されたエンジニアは、ツールと戦うのではなく、顧客の問題を解決します。AIコーディングアシスタントや効率的な検証プロセスにアクセスできる開発者は、手動で構築するのに数週間かかるソリューションを迅速にプロトタイプし、反復することができます。効率的なレビューと自動化されたデプロイメントは、アイデアが顧客に届くスピードを根本的に変えます。その影響は非常に大きいのです。開発者の生産性がわずかに向上するだけでも、 摩擦を取り除くことで、イノベーションの成果や市場への対応力が劇的に向上します。開発者の満足度を高め、彼らが集中して仕事を進める能力を向上させることは重要ですが、これは単なる開発者の快適さの問題ではなく、ビジネスの成長を制限してきた目に見えない負担を取り除くことに関わっています。開発者体験（DevEx）は多くの意味を持ちますが、私たちはまず摩擦を減らすことから始めます。数百の組織で開発者やリーダーと協力してきた中で、DevExの改善が人によって異なる意味を持つことを見てきました。 1. 摩擦の削減。開発者体験の改善を摩擦の削減として捉えることで、チームは何を探すべきか（遅延、障害、混乱、複雑さ、非効率）を容易に理解し、それを取り除くために取り組むことができます。また、ビジネスリーダーと話す際には、ソフトウェアの提供にかかる遅延が顧客へのサービス提供、収益の加速、市場シェアの獲得にどのように影響するかを伝えることができます。 2. 組織戦略。企業が摩擦を減らし、開発者体験を改善することに投資する場合、私たちはしばしば「DevEx戦略」や「DevExチーム」と呼びます。この場合、DevExの改善は、開発者体験が摩擦を取り除くことに関わるという考え方、ソフトウェアの摩擦が可能な価値を減少させるというビジネスの理解、そしてそれを改善するための正式な支援（リソース、資本、リーダーシップとの定期的な報告など）を含みます。 3. データとインサイトの源。多くの組織において、「DevEx」は開発者の生産性や体験を伝える指標、ダッシュボード、報告を指します。これには、システム生成データ（デプロイ頻度、ビルド時間、失敗率など）や、調査やインタビューからの定性的なフィードバックが含まれます。これらの測定は、データや指標に対する共通の理解を持って行われると、エンジニアリングチームとリーダーシップの間で重要な共通言語となることがありますが、各チームはそれぞれの視点が必要です。具体的には、エンジニアリングチームはトラブルシューティングや最適化のための詳細な指標から利益を得る一方で、リーダーシップは戦略的な意思決定を行うために高レベルのトレンドやビジネスへの影響を必要とします。 この本では、DevExの改善の基盤として摩擦の削減から始め、その基盤をもとに戦略、測定、組織のサポートを構築する方法を示します。このアプローチは、組織の文脈に関係なく即座に実行可能であり、個々のチームは正式なイニシアチブや専用リソースを必要とせずに摩擦点を特定し、対処できます。しかし、私たちはまた、戦略的なフレームワーク、有意義な指標、変革管理アプローチを通じて、これらの取り組みを拡大する方法も案内します。これにより、組織全体で持続的なDevExの改善を築く手助けをします。 「生産性」という言葉は警鐘を鳴らしますが、「体験」という言葉は会話を生み出します。摩擦を減らし、ビジネス成果を加速させることに焦点を当てることは生産性に関連していますが、その言葉には重荷が伴います。 「生産性」という言葉は、しばしば単純化された指標やマイクロマネジメントへの恐れを引き起こします。これは、マネージャーが効率性や標準化を追求することで、開発者の自律性、創造性、仕事の満足度が犠牲になるという、古典的なテイラー主義を思い起こさせます。また、グッドハートの法則も思い出させます。すなわち、ある指標が目標になると、それは良い指標ではなくなるということです。これにより、チームは意味のある成果ではなく、指標の最適化を目指すようになります。それに対して、「体験」という言葉は、障害を取り除き、より良い仕事を可能にすることに焦点を当てることを示唆しています。開発者体験（DevEx）と生産性は必ずしも同じではありませんが（この点については後で詳しく説明します）、改善のために信頼と勢いを築こうとする際には、フレーミングが非常に重要です。生産量ではなく体験に焦点を当てることで、開発者が最高の仕事をするために本当に必要なことを探求する余地が生まれます。これが、私たちの三部構成のフレームワークの出番です。 **PART II** **DevExの三つの重要な要素** あなたは今、開発者体験を理解し、改善するための基盤を持っています。DevExは開発者の特典や満足度についてではなく、ビジネス全体を制約する摩擦を体系的に取り除くことに関するものです。開発者がツールと戦ったり、フィードバックを待ったり、複雑なプロセスをナビゲートしたりするのにエネルギーを使っていると、革新や問題解決に使える余力はほとんど残りません。私たちの三要素のフレームワークは、この摩擦を特定し対処するための実践的な視点を提供します。それは、意思決定を加速するためのフィードバックループの最適化、深い作業を最大化するためのフローステートの保護、複雑な課題に対処するためのメンタルキャパシティを解放するための認知負荷の軽減です。これらの要素は持続可能なように設計されています。AIや新しい技術が具体的なツールや手法を変えても、彼らが解決する基本的な開発者のニーズは変わりません。これらの要素は相互に強化し合います。一つの領域での改善が他の領域での利益を引き出すことが多く、開発者の生産性とビジネスの成果の両方に複利的な利益をもたらします。 **第4章** **DevExフレームワーク** 三つの重要な要素が、あなたのDevExを良いものから素晴らしいものへと引き上げます。開発者体験をより具体的に考えるためのフレームワークはいくつか存在しますが、私たちはフィードバックループ、フローステート、認知負荷という三つの特定の要素に焦点を当てた、シンプルで包括的なものを開発しました。これらの三つの要素は、開発者の日常業務の技術的および心理的な側面を捉えているため選ばれました。開発者が同じ場所にいる場合でも、異なるタイムゾーンに分散している場合でも、AIツールによってますます補完されている場合でも、これらの要素は重要です。フィードバックループ、フローステート、認知負荷の三つはそれぞれ個別に重要ですが、互いに強化し合うこともあります。たとえば、迅速なフィードバックを得ることはすべての仕事において重要であり、開発者にとっては、質問に対する迅速な回答を得たり、ドキュメントを見つけたり、ビルドが成功したかどうかを知ったりすることが含まれます。 遅いフィードバックループは、開発者が別のタスクに移ってしまう原因となり、フロー状態を中断させます。これは、同期的なコミュニケーションの時間が限られている分散チームにおいて特に深刻な課題です。AIアシスタントは、こうしたギャップを埋める手助けをし、共通の質問に対する即時の回答や、人間の同僚が不在の際のデバッグ支援を提供します。遅れたフィードバックがようやく届くと、開発者は以前のタスクに戻るために再びスピードを上げなければならず、これが認知負荷に悪影響を及ぼします。これらの三つの要素をうまく最適化できる組織は、デプロイ頻度、リードタイム、製品品質の向上を実感でき、これらはすべて収益成長、市場への対応力、価値提供に直接的かつポジティブな影響を与えます。 第5章 フィードバックループ 迅速なフィードバックは、イノベーションと品質を加速させるための掛け算です。迅速なフィードバックループは、開発者がコードが正しく機能しているか（正確性、パフォーマンス、安全性）やアイデアが良いか（主要なビジネスメトリクスを改善するか）を知る手助けをします。これは明白に思えるかもしれませんが、チームや組織は「これまでずっとこうだったから」や「待っている間に他のことができる」といった理由で、遅いフィードバックループを容認しがちです。また、「他の人は問題ないようだ」や「これは優先事項ではない」といった声も聞かれます。しかし、迅速に価値を創造することは、システムの遅延やボトルネックを減らすこと以上の意味があります。それは、開発者が効率的に作業できるように重要な文脈や情報を提供することでもあります。 遅いフィードバックは開発プロセスを中断させます。これにより、開発者は待たされるか、タスクを切り替えることを決定することで、フラストレーションや遅延が生じます。場合によっては、遅いフィードバックループに苛立った開発者が、コードレビューをスキップしたり、未テストの変更をマージしたり、確立されたプロセスに従わずにデプロイしたりするなど、摩擦を避けるためのリスクの高いショートカットを見つけることがあります。もちろん、これにより全く新しい問題が発生します。 遅いフィードバックループは、システムからのフィードバック（統合テストの実行結果など）や人からのフィードバック（レビューのメモなど）が返ってきて、即座に対応が必要になるときにも追加の中断を引き起こします。これは次の要素である認知負荷に直接関連しています。フィードバックループが遅くなるほど、開発者は自分のメンタルモデルを「再構築」し、必要な作業を行うのが難しくなります。キューイング理論のリトルの法則は、フィードバックの遅延がなぜこれほどコストがかかるのかを説明しています。遅延が長くなるほど、開発者は同時に処理しなければならない作業中のタスクが増え、作業メモリが圧倒されてしまいます。マイクロソフトリサーチとカリフォルニア大学アーバイン校の研究は、この効果を確認しています。テスト結果を待っている間に15～30分の中断があると、文脈の切り替えが発生し、開発者の生産的な時間の15～30％を無駄にする可能性があります。 フィードバックループを短縮するためには、開発者がよく情報を必要とし、それを得るのに遅れが生じる領域を特定することが重要です。ここでの良い例は、成果の結果です。 自動化ツールやプロセス（例：ビルドやテストの結果、開発環境の設定）と、同僚から必要な情報（例：引き継ぎやコードレビュー）を活用することで、AIツールはフィードバックの迅速化にも寄与します。これにより、コードベースに関する質問やコーディングソリューションの提案を、同僚に尋ねたりドキュメントを探したりするよりも早く得ることができます。これらの改善を優先することで、組織は迅速な納品と高品質な作業を実現し、次の章で取り上げる「フロー状態」をサポートします。 ### 第6章 フロー状態 フロー状態とは、優れた開発者を偉大な開発者に変える生産性の倍増器です。開発者が「フローに入る」や「ゾーンにいる」と言うとき、彼らはフロー状態について話しています。これは、活動に完全に没頭し、エネルギーを持って集中し、個人的な楽しみを感じる状態です。この状態に入り、できるだけ長く留まることは、複雑な問題を解決したり、難しいコードベースのデバッグを行ったり、創造性を育むために重要です。カル・ニューポートが深い仕事に関する研究で主張しているように、複雑な認知タスクは、意味のある結果を生み出すために持続的で集中した時間のブロックを必要とします。この必要性は、ソフトウェアシステムがますます複雑になるにつれて一層強まっています。マイクロサービスアーキテクチャ、分散システム、AI統合は、これまで以上に深い集中を要求する文脈を生み出します。組織の構造もフローを妨げることがあります。重要な開発者がその専門知識のために繰り返し会議やスコーピングセッションに引き込まれると、深い集中を維持する能力が損なわれます。研究によれば、職場でのフロー状態は生産性、革新性、満足度、学習を高めることが示されています。また、専門家がこの最適なメンタル状態を達成すると、著しく生産性が向上することも示唆されています。 効果的なフィードバックループは、フローを維持するために重要です。フィードバックがタイムリーで信頼できるものであれば、開発者は自分の作業に没頭し続けることができます。ここでAIツールが特に役立ちます。質問に迅速に答え、開発者の障害を取り除くことで、フローを維持させるのです。しかし、壊れたフィードバックループや遅いフィードバックは中断を引き起こし、フローを破壊します。これは、テスト結果の遅延によって数時間または数日後に文脈を切り替えなければならない場合や、即座の対応が必要な不安定なテストが原因です。最後に、仕事における自律性や充実感もフローに寄与します。これにより、開発者は自分のタスクに完全に没頭できるからです。研究によれば、自分の仕事を楽しんでいる開発者は、より良いパフォーマンスを発揮し、高品質な製品を生み出すことがわかっています。 これを実際にどう活かすかというと、ツールや自動化、フィードバックループの改善、プロセスの簡素化、または中断の最小化を通じてフロー状態をサポートする方法を見つけることでDevExを向上させることができます。例えば、チームは会議を再配置して集中作業のための時間を確保したり、反応的な作業を避けるために品質ゲートを改善したり、助けやコードレビューのリクエストをまとめて行うことができます。 リーダーは、フロー状態が開発者に自律性を与え、充実した課題に取り組む機会を提供するポジティブなチーム文化の構築に依存していることを認識する必要があります。これは、ツールやプロセスの最適化を超えて、心理的安全性を積極的に構築し、意味のあるプロジェクトの所有権を提供し、開発者に技術的な決定を下す自由を与えることを意味します。これらの文化的要素が整うと、深い集中状態が自然に生まれ、常に維持するための努力を必要としなくなります。 リモートおよびハイブリッドワーク：開発者体験の課題と機会。リモートおよびハイブリッドワークへの移行は、開発者体験を根本的に変え、新たな摩擦点と予期しない利点を生み出しました。 新たな課題： - ビデオ通話を介したミーティングのオーバーヘッドがフローをより深刻に妨げます。 - 非同期コミュニケーションの遅延がフィードバックループを遅くし、特にタイムゾーンを跨ぐ場合に顕著です。 - 自宅環境の気晴らしが深い集中を達成するのを難しくします。 - タイムゾーンを跨いで働くことがスケジュールの摩擦を生み出し、チームメンバーを重要な決定から排除します。 - 「ズーム疲れ」が複雑な問題解決のための認知能力を低下させます。 隠れた機会： - フレキシブルなスケジュールにより、開発者はエネルギーが最も高い時間帯に働くことができます。 - AIを活用したミーティングの文字起こしやノート作成ツールは、出席に関係なくミーティングをアクセス可能にすることで、グローバルチームをサポートします。 - オフィスでの中断が減ることで、フロー状態の持続時間が実際に改善されることがあります。 - 個別に最適化されたホームオフィスが、各自の作業スタイルに合った環境を提供します。 - グローバルな人材へのアクセスにより、適切に管理すれば24時間の開発サイクルが可能になります。 - よく計画されたミーティングのスケジュールとアジェンダが、作業時間を断片化するのではなく、予測可能な集中時間を生み出します。 リモート組織にDevEx戦略をうまく適応させた組織は、しばしばリモート前のレベルを超える生産性の向上を見込むことができます。重要なのは、単にオフィスの慣行をビデオ通話に翻訳するのではなく、分散作業のために意図的に設計することです。 第7章 認知負荷 ソフトウェアを書くことはすでに複雑であり、さらに難しくするべきではありません。開発者は、複雑なシステムや大規模（時にはレガシー）のコードベース、相互依存関係から、使用するツールや技術の数が増えることで、ますます大きな認知負荷に直面しています。DevExの文脈において、認知負荷とは「開発者がタスクを実行するために必要な精神的処理の量」を指します。例えば、難しいタスクは認知負荷が高く、複雑なインターフェースや複数のシステムやツールを使う必要がある場合も認知負荷が増加します。認知負荷は情報の提示方法によって変わり、情報を長期的なドメイン知識やモデルに変換するために精神的処理が必要な場合に増加します。過度の認知負荷は、開発者が顧客に価値を提供する能力を直接妨げます。 開発者が文書化が不十分なコードや断片化されたシステム、あるいは手作業で繰り返し行う作業（持続的な価値を提供しない手動のコンプライアンスチェックなど）に直面すると、日常的なタスクを完了し、ミスを避けるために、余分な時間と精神的エネルギーを費やさなければなりません。この課題は、レガシーシステムで作業する際に特に深刻です。開発者は、歴史的なアーキテクチャの決定を理解し、技術的負債を回避し、現代のツールやプラクティスと統合する必要があります。頻繁な中断は、流れを断ち切り、コンテキストスイッチを強いることで問題をさらに悪化させ、生産性を低下させ、精神的負担を増加させます。このサイクルは開発を遅らせ、エラー率を上昇させ、時間が経つにつれて燃え尽き症候群を引き起こします。開発者は自動化できる低価値の作業に貴重な認知能力を費やすことになります。認知負荷と他の二つの要素との関係は明確です。不要な精神的努力が手作業や冗長な作業に費やされることで、難しく魅力的な問題に集中し、フロー状態を達成することが難しくなります。また、遅いフィードバックループは、コンテキストスイッチの際に開発者がメンタルモデルを再構築する必要があるため、認知負荷を増加させます。これにより、開発者体験が著しく悪化するサイクルが生まれます。解決策は、不要な複雑さを体系的に削減することです。開発者体験を改善するために、チームや組織は開発プロセスの障害を取り除くことで不要な認知負荷を減らすことを目指すべきです。整理されたコードと文書は、開発者が作業するシステムを理解するのを助け、プロジェクトを完了するために必要なコンテキストやタスクの切り替えを減少させます。専任の開発者体験やプラットフォームチームは、開発とリリースのステップを効率化するための使いやすいセルフサービスツールを提供できます（これらのツールやチームの構築に関する具体的なアプローチは第52章で探ります）。これには、異なるプラットフォームやプロセスを管理する際の認知的オーバーヘッドを避けるために、ツール選択に関する組織的な調整が必要です。目標は、開発者が避けられる複雑さに悩まされるのではなく、仕事の本質的な複雑さを解決するために精神的エネルギーを集中できるようにすることです。AIは認知負荷に対して機会とリスクの両方を提供します。AIツールは、開発者がルーチン作業を迅速に進めるのを助けることで認知負荷を軽減できます。しかし、AIは複雑なタスクを中断したり、レビューが難しく長期的に維持が高コストなコードを生成したりすることで、認知負荷を増加させる可能性もあります。目標はAIを避けることではなく、その利点を最大限に活用しつつ、欠点を積極的に最小限に抑えることです。 第8章では、フレームワークを使用して摩擦を特定し、取り除く方法を説明します。DevExの三つの要素は、摩擦を見つけて修正するためのフレームワークを提供します。DevExの要素を改善するために行う行動は、摩擦を減少させます。そして、取り除きたい摩擦を考えるとき、それをこれらの要素のいずれかに関連付けることが役立つ場合があります。 それは、より良いソリューションを設計し、それを測定するためのより良い方法を考えるのに役立ちます。（メトリクスについては、ステップ3で詳しく説明します。）これは単なるフレームワークの話ではなく、行動と実行に関するものです。開発者体験の三つの次元—フィードバックループ、フロー状態、認知負荷—を理解することで、摩擦を特定するための強力な視点を得ることができます。しかし、問題を特定することは戦いの半分に過ぎません。それを解決するためには、構造化されたアプローチが必要です。悪化した開発者体験（DevEx）は、開発者だけでなく、組織全体に高額な波及効果を生み出します。開発者体験は、仕事における摩擦に関するものであり、摩擦は誰にとってもコストがかかります。開発者が遅いビルドや複雑なインフラ、断片化したツールに苦しむと、その影響は広がります。 - 企業にとっては、市場投入までの時間が遅れ、非効率なプロセスからのクラウドコストが増加し、競争優位性が低下します。 - リーダーにとっては、予測不可能な納期、計画の難しさ、優秀な人材の確保に苦労します。 - チームにとっては、作業の調整のために会議が増え、コンテキストの切り替えが増加し、コラボレーションが減少します。DevExの改善に焦点を当てることの美しさは、改善が相乗効果を生むことです。一つの領域で摩擦を減らすと、他の領域でも予期しない利益が得られることがよくあります。いくつかの懸念は特別な解決策を必要とするかもしれません（例えば、中断を最小限に抑えることや作業定義を明確にすることなど）が、体系的な摩擦ポイントに対処することで、初期投資を大きく上回る組織全体の効率向上が得られます。次の章で見ていくように、DevExの強力なビジネスケースを作成することは、これらの摩擦ポイントをリーダーシップがすでに関心を持っているメトリクスに直接結びつけることを意味します。 ### 第3部 ビジネスケースを作成する 開発者体験（DevEx）とそのビジネスへの影響を理解することは、始まりに過ぎません。本当の課題は、意味のある改善を行うために必要なリソースと組織のサポートを確保することです。ほとんどのDevExイニシアチブが失敗するのは、技術的な実行が不十分だからではなく、意思決定者にその価値を効果的に伝えられないからです。この部分では、成功したチームが開発者の痛点をどのように魅力的なビジネスケースに変換し、経営陣に響くようにしたのかを探ります。DevExの改善を財務成果に結びつけ、既存の戦略的優先事項と整合させ、リーダーシップの最も重要な懸念に対する解決策として自分の仕事を位置付ける方法を学びます。これらのアプローチは持続可能なように設計されています。あなたが提唱する具体的なツールや技術はAIや他の革新とともに進化しますが、問題を調査し、データを収集し、ビジネス価値を伝えるための基本的な方法は変わりません。DevExの改善のための初期資金を求めている場合でも、既存の投資を守る場合でも、これらの章ではリーダーシップの支持を得るための実証済みのアプローチを示します。 ### 第9章 開発者体験をビジネス価値に変換する C-suiteの幹部は、ビジネス成果の言語を話します。 「開発者の満足度を向上させる」や「リードタイムを短縮する」といった目標はエンジニアリングリーダーには響くかもしれませんが、経営層は明確な財務的影響を見たいと考えています。ビジネスリーダーは、収益成長、利益率、市場シェアといった指標で評価されるため、あなたの開発者体験（DevEx）提案はこれらの財務的成果に直接結びつかなければなりません。これは、経営者が開発者の幸福を気にしていないということではありません。むしろ、開発者体験への投資がどのようにビジネスの結果に結びつくのかを理解する必要があるのです。この財務的な枠組みは、戦略を売り込む際（ステップ5）や価値を示す際（ステップ7）に非常に重要です。 時間の回復について話しましょう。開発者の時間をドルの価値に換算します。開発者の時間には明確な財務的価値があります。以下のようにできます： - 不必要な作業やビルド/テストの待機に費やした時間を測定します。 - この時間に開発者のフルコストを掛け算します。 - これらの節約を「回収された生産性のドル」や「無料の人員」として提示します。 例えば、50人の開発者がそれぞれ毎週5時間をビルド関連の遅延に無駄にしている場合、フルコストが時給100ドルであれば、週に25,000ドルの生産性損失、年間では130万ドルになります。また、これを「無料の人員」として表現することもできます。例えば、50人の開発者 × 週に失われた5時間 = 合計250時間の無駄です。40時間の労働週を基にすると、予算を増やさずに6.25人の追加の開発者を得たことに相当します。この枠組みは、採用凍結が行われている時や労働市場が厳しい時に特に響きます。信頼性を守るためには、実際の信頼できる時間の節約を測定することが重要です。 財務的な影響は大きいです。チームが開発者体験を改善すると、その利益は累積します。25万ドルの開発者が、ツールの摩擦を避けることでわずか10％の時間を回復すれば、25,000ドルの価値が回収されます。これを全体のエンジニアリング組織に掛け算すると、数十人または数百人の「無料」の開発者に相当します。しかし、利益はそれだけではありません。より迅速なツールチェーンにより、組織はより早く構築、実験、反復ができ、数百万ドルに達するビジネス価値を生み出します。そして、納期、チームの士気、顧客満足度への累積的な影響を考慮する前の話です。 Etsyの250万ドルのDevEx投資：ビジネスケースの実例。Etsyのエンジニアリングチームが250人からほぼ1,000人に急成長する中で、リーダーシップは開発者体験への投資なしでは生産性が低下することを認識しました。CTOのマイク・フィッシャーは、賛同を得るためのアプローチをシンプルにしました：改善をビジネス用語に翻訳することです。デプロイメントプロセスの技術的な変更を説明する代わりに、彼は経営者に対して、その作業がデプロイメントを待つために費やされるエンジニアリング時間の50％を節約することになると伝えました。これは、フルタイムのエンジニアの給与の4分の1に相当します。 その結果、エンジニアリングの20％のリソースを4つの重要な分野での開発者体験（DevEx）の改善に充てるイニシアティブが誕生しました。これらの分野は、製品の設計、開発と展開、データを活用した構築、そして作業の負担を軽減することです。このイニシアティブは18ヶ月を要しましたが、非常に成功を収めたため、開発者体験に関する取り組みへの継続的な投資が行われ、Etsyの標準的な運営に統合されました。彼らの重要な洞察は、「人、プロセス、技術を一緒にスケールさせなければ、生産性は成長に関係なく低下する」というものでした。 コスト削減について話しましょう：コスト削減を定量化します。改善された開発者体験は、財務諸表に直接影響を与える具体的なコスト削減をもたらします。自動化を強化し、ワークフローを効率化し、冗長性を排除することで、運営費用を大幅に削減できます。例えば、戦略的なDevExへの投資は以下のような効果があります： - プロセスの最適化とツールの統合を通じて、ベンダーコストを削減。 - テストの効率を向上させることで、クラウドコンピューティングの費用を削減（冗長なテストを排除）。 - 処理能力を少なくする最適化されたビルドプロセスを通じて、インフラコストを削減。 - より良い品質管理によって、高額な生産事故を最小限に抑える。 ビジネスケースを作成する際は、可能な限り具体的な予測を伴ったこれらの具体的なコスト削減に焦点を当てましょう。これには、開発者が摩擦を減らして機能をより迅速に提供することによる配信コストの即時削減と、改善された人材の定着による長期的なコスト削減が含まれます。経営者は、出力の質を維持または向上させながら、明確な経費削減の道筋を示すイニシアティブに強く反応します。 戦略的な標準化：Blockが数百万ドルの節約を実現した方法。Blockは、Square、CashApp、Tidalなどのブランドで構成される先進的なフィンテック企業です。彼らは単なる標準化を追求するのではなく、開発者のために十分にサポートされた「ゴールデンパス」を作成するためにツールの統合にDevEx戦略を集中させました。ビジネスケースを作成する際、Blockのチームは開発者の満足度やコードのスループットといった抽象的な利益に焦点を当てることもできましたが、代わりにエンジニアリングの摩擦や回避可能な信頼性の問題がビジネスに与えるドル単位の影響に注目しました。このビジネス重視のアプローチは成功を収め、彼らの開発者体験イニシアティブは資金を得て、12ヶ月で印象的な結果をもたらしました。より良い開発者環境、ゴールデンパス、AIツールへの投資のおかげで、彼らは数百万ドルの文書化された節約を実現し、開発者の満足度スコアを二桁改善しました。 お金を生み出すことについて話しましょう：DevExを通じて収益を加速させる。開発者体験のイニシアティブは直接的な収益源ではありませんが、既存の収益ストリームを大幅に加速させます。ソフトウェア主導の企業にとって、収益成長は以下の5つの重要な要素に依存しています： 1. 機能の速度（新しい機能が顧客に届く速さ）。 2. 機能の質（新しい機能が顧客のニーズをどれだけ満たすか）。 実験のスピード（新しいアイデアをどれだけ迅速にテストし、反復できるか）、サービスの信頼性（製品がどれだけ一貫して機能するか）、セキュリティの姿勢（顧客データと信頼をどれだけ守れるか）という5つの要素は、すべて効果的な開発者のワークフローに依存しています。AIの変革を考えてみましょう。企業がAI機能を製品に統合するために競争している中で、収益の増加、競争優位性の獲得、市場シェアの拡大を目指しています。しかし、これらのAI機能は次のようにしなければなりません： + 設計され、コーディングされること。 + 品質がレビューされること。 + 構築され、テストされること。 + 既存のシステムや製品に統合されること。 + 安全に展開されること。 + 維持され、改善されること。 開発者が最適でないツールや断片的なプロセスに悩まされると、これらの技術的なボトルネックがビジネスの問題となります。企業は市場投入の遅れ、品質の低下、セキュリティの脆弱性に直面し、これらはすべて収益に直接影響します。考えてみてください。もし競合他社が四半期ごとにAI機能をリリースする一方で、あなたのチームがワークフローの非効率性のために6ヶ月かかるとしたら、単に技術的な負債が蓄積されるだけでなく、実際の収益損失や市場での関連性の低下を経験しているのです。賢明なDevExへの投資は、既存のチームがより迅速に多くの価値を提供し、収益源を強化し、競合他社よりも早く市場機会を捉えるという乗数効果を生み出します。 収益成長の加速： キャピタルワンのDevEx変革。キャピタルワンは、開発者体験とクラウドインフラに戦略的に投資することで、市場での地位を劇的に変革しました。DevExの見直し前は、新しい金融商品を立ち上げるのに6〜9ヶ月かかり、企業の競争力が制限されていました。開発環境を標準化し、最新のCI/CDパイプラインを導入し、クラウドネイティブ技術を採用することで、キャピタルワンは納期を数ヶ月から数週間、あるいは数日に短縮しました。そのビジネスへの影響は迅速かつ測定可能でした。より早い展開サイクルにより、キャピタルワンは競合他社よりも早く市場機会を捉え、顧客のニーズに迅速に対応し、迅速な反復を通じて収益を生む機能を最適化できました。キャピタルワンは、DevExへの投資を市場投入の加速や顧客獲得に直接結びつけることで、経営陣の支持を得ました。これらの指標は、収益成長に直接つながるものです。彼らのストーリーは、開発者のワークフローを改善することが単なる技術的な勝利ではなく、強力な収益加速器であることを示しています。 実証された相関関係について話しましょう： 技術的な指標をビジネスの成果に結びつけること。時には、最も強力なビジネスケースは、技術的な指標とビジネスの成果との相関関係を特定することから生まれます。ダグラス・ハバードの著書『How to Measure Anything』では、「もし二つの事柄を相関させることができ、さらにそのうちの一つをお金に相関させることができれば、両方をお金の観点で表現できる」と述べています。eBayでは、ページスピードが10ミリ秒改善されるごとに、数百万ドルのウェブ購入の増加につながるという画期的な分析が示されました。 この相関関係は、ビジネスがページスピードをどのように捉えるかを変革しました。技術的な懸念から、投資に値する重要な収益ドライバーへと変わったのです。このアプローチの具体例として、DXによって開発された「開発者体験指数（DXI）」があります。DXIスコアは、開発者の開発プロセスのさまざまな側面について尋ねる14の調査質問の平均値です。このスコアと自己報告による時間損失を相関させることで、DXはDXIスコアが1ポイント上がるごとに、開発者1人あたり週に13分、年間で10時間の時間を節約できることを発見しました。この相関関係により、組織はDevExの改善からの財務的影響を予測できるようになります。この同じアプローチを開発者体験に適用することができます： - 開発者の満足度スコアと市場投入までの時間の短縮を相関させる。 - ビルドシステムの信頼性と生産事故の減少を結びつける。 - オンボーディング体験の改善と新入社員の生産性向上を関連付ける。 ただし、開発者の生産性指標を直接収益に結びつけようとすることには注意が必要です。これはこの分野でよくある間違いです。DevExのリーダーたちはこれを試みますが、どこから始めればよいかわからず、最終的には自分たちの仕事の価値を経営陣に納得させることを諦めてしまいます。数字の正確さよりも、ストーリーテリングが重要です。DevExのビジネスケースを構築する際には、完璧を求めることが良い結果の敵です。多くのリーダーは、正確なROI数値を計算しようとしたり、完璧なデータを集めようとしたりして行き詰まりますが、この完璧主義はほとんどの場合必要ありません。ほとんどの状況では、信頼できるデータがあれば十分です。本当に重要なのは、そのデータをどのように魅力的な物語に織り込むかです。データポイントは良い見出しや証拠となりますが、意思決定者にとって意味のあるものにするためには、明確で簡潔なストーリーが必要です。覚えておいてください：どんなに印象的な数字でも、自らを語ることは稀です。あなたのプレゼンテーションスキル、物語の構造、そして聴衆の優先事項を理解することが、最終的にあなたのビジネスケースの成功を決定します。この点については、ステップ5「戦略を売り込む」でさらに詳しく説明します。 第10章 他者が気にかけることとあなたの仕事をつなげる リーダーシップの支持を得るためには、開発者体験がどのように彼らの具体的なビジネス問題を直接解決するかを示すことが重要です。多くのリーダーにとって、開発者体験は最優先事項ではなく、改善に向けて団結するのが難しいのです。したがって、開発者体験を広めるためにエネルギーを費やすのではなく、パフォーマンス目標の達成、ボーナスの確保、キャリアの向上、または平均的な技術系幹部の在職期間が2年未満の分野での地位を維持することなど、経営陣が気にかけることに結びつけることに焦点を当てましょう。あなたのDevExの取り組みを、CEOやCTOを夜も眠れなくさせる問題に合わせて調整してください。リーダーシップの重要な理解を把握することで、開発者体験の取り組みを彼らがすでに優先している観点から提示することができます。DevExのメッセージを既存の経営陣の優先事項に合わせることで、注意を引くために競争するのではなく、戦略的な目標を直接支援する存在に変わります。 ブロックがDevExレポートを戦略的優先事項に変えた一言の変更 ブロックの開発者体験（DevEx）チームが、彼らの調査結果と機会を文書化した「開発者体験の現状」レポートを準備していたとき、出版直前に重要な方向転換を行いました。「エンジニアリングの速度」を重要なビジネスの優先事項として認識したチームリーダーのアズラ・コバーンは、すぐにレポートの名称を「エンジニアリングの速度の現状」に変更しました。その結果は驚くべきものでした。CTOはこのレポートを熱心に支持し、その広範な配布を推奨しました。内容は変わらなかったものの、戦略的な名称変更はリーダーシップの明確に表現された優先事項と完璧に一致しました。このシンプルな再定義は、標準的なレポートをCEOの最も差し迫った懸念に対処するタイムリーなソリューションに変えました。この例は、上級リーダーが夜も眠れない理由を理解し、DevExの取り組みをそれらの優先事項に直接関連付けることの重要性を示しています。これにより、注意を引くために競争するのではなく、自然な味方を作ることができます。 会社の最も重要な優先事項に結びつける DevExの取り組みは、会社の最も重要な目標を直接支援する場合に即座に traction（牽引力）を得ます。開発者体験を別の懸念として位置付けるのではなく、既存の戦略的優先事項を加速するものとしてフレーム化しましょう。 プラッドがDevExをコストセンターから戦略的な推進力に変えた方法 フィンテック企業プラッドでは、ユーザーの銀行口座をデジタル体験に統合するソフトウェアを構築していますが、彼らのDevExリーダーは当初、リーダーシップにチームの価値を納得させるのに苦労していました。エンジニアリングの効率指標や潜在的なコスト削減について数週間議論しても、経営陣の賛同を得ることはできませんでした。新しいアプローチの必要性を認識したこのリーダーは、エンジニアの3分の1がCEOによって最優先（PO）と見なされた新しい製品開発イニシアチブに再配置されていることを特定しました。遅延が続くことで、会社の市場ポジションが脅かされる可能性がありました。一般的な効率指標を押し続けるのではなく、彼らはチームの使命を再定義しました。それは、この重要な製品開発を特に加速することです。DevExを会社の最も緊急な優先事項を直接支援するものとして位置付けることで、彼は瞬時にCEOの承認を得ました。この戦略的な方向転換は、重要な原則を示しています。既存の会社の優先事項、特にPOとラベル付けされたものを支援するものとして位置付けられたDevExの取り組みは、孤立して提示されたものよりもはるかに多くの支援を受けるのです。 DevExの取り組みを組織の最も差し迫ったビジネス目標に直接結びつける 上級リーダーに自慢できるものを提供する すべてのリーダーは、自身のパフォーマンスレビューで強調できる成果が必要です。CTOはCEOに報告し、CEOは取締役会に報告します。すべての人が自分の効果を示すための具体的な成果を求めています。開発者体験の取り組みを位置付ける際には、成果をリーダーシップが自分のパフォーマンスレポートでクレジットを主張できる印象的な指標としてフレーム化しましょう。取締役会に「私たちはエンジニアリングの速度を向上させました」と言えるCTOは、確実に評価されるでしょう。 「15パーセント減少しました」や「DevExプログラムを実施してから、残念な離職率を20パーセント減少させました」といった具体的な数字は、リーダーシップの影響を示すための強力な武器となります。パフォーマンスのギャップを明らかにすることが重要です。リーダーはしばしば、開発者体験において何が可能かを知らず、そのためパフォーマンスのギャップがそれほど緊急ではないように感じてしまいます。他社がどのような取り組みをしているかを示すことで、「ああ、そうか！」という瞬間を生み出し、変革を促すことができます。たとえば、リーダーが同様の企業が数時間でコードをデプロイしている（数週間ではなく）、または開発者がビルド失敗に費やす時間が30パーセント少ないことを知ったら、なぜ自社がそこに到達していないのかを知りたくなるでしょう。これは競争の問題ではなく、可能性を認識させることが重要です。このアプローチは、可視性が重要な対話を始める助けになるからです。誰もが悪く見られたくはありませんが、もっと重要なのは、誰もが高いパフォーマンスが達成可能であるのに、平凡さを受け入れていることに気づきたくないということです。開発者体験を単なる技術的なニーズから戦略的なビジネスの推進力へと再定義することが重要です。成功するDevExの提唱は、開発者体験を説くことではなく、それをビジネスの成果に結びつけることです。経営陣の優先事項に合わせ、重要な企業の取り組みを支援し、リーダーが示せる指標を提供することで、DevExを技術的な懸念から戦略的な利点へと変えることができます。投資を提唱する際には、「どうすれば彼らに開発者体験を大切にさせることができるか？」ではなく、「私の仕事は彼らの最も差し迫った問題をどう解決するか？」と問いかけてください。この視点は懐疑的な人々を味方に変えます。 **第4部: DevExの改善：7ステッププロセス** 開発者体験の改善は偶然には起こりません。体系的なアプローチが必要であり、測定可能な結果を出しながら勢いを築くことが求められます。以下の7つのステップは、単一のチーム内であれ、全社的であれ、DevExの改善を推進するための実用的なフレームワークを提供します。私たちの7ステッププロセスが実施をガイドします。 ステップ1と2では、DevExの旅を始める方法と、3つの要素全体で最も破壊的な摩擦点を特定することで迅速な成果を得る方法を学びます。ステップ3と4では、データを使用して摩擦の影響を測定し、最も影響の大きい領域から優先的に対処する戦略を策定する方法を示します。ステップ5と6では、DevExの改善をビジネスの成果に結びつけることで、利害関係者に戦略を売り込む方法を学び、組織に適した規模での変革を推進します。最後に、ステップ7では、3つの要素全体での改善を測定し、そのビジネス価値を示すことで進捗を評価するためのツールを提供します。このプロセスは直線的ではなく、反復的に設計されています。これらのステップを何度も繰り返し、各反復が前回の洞察と信頼性を基に構築されます。自分の状況に合ったところから始め、各ステップを完璧にすることを心配しないでください。 前に進むためのステップ—重要なのは、勢いを維持しながら、常に学び、アプローチを適応させることです。 **ステップ1: DevExの旅を始める** 新しい会社でのスタート、既存の会社での新しい役割に就いてDevEx改善の取り組みを始める、または草の根の努力をまとめる場合でも、まずは顧客、つまり開発者と話をすることから始めましょう。彼らに、どのように仕事を進めているのか、好きなツール、愛用しているテクニック、イライラすること、新しいエンジニアのオンボーディングを難しくする要因、摩擦を生むツールやプロセスについて話してもらいましょう。開発者は、自分たちのシステムが素晴らしい部分と壊れている部分についてのストーリーを共有するのが好きです。このステップを省略しないでください。これにより、長年その組織にいる場合でも見逃してしまう問題が明らかになります。問題が開発者にどのように影響を与えているのか、具体的な例やストーリーを通じて理解することができます。また、開発者に彼らの意見を重視していることを示すことにもなります。 変革管理の観点から、経営陣の支援を確保することは最優先事項です。支援が不十分であることは、イニシアティブの成功に対する最大の障害となることが多いです。しかし、実際には、経営陣が支持するための説得力のあるケースを構築するために、開発者の洞察が必要になることがよくあります。これにより、戦略的な選択が生まれます。ケースを構築するために発見から始めるか、すでにDevExの問題に関する明確な証拠がある場合は経営陣の調整から始めるかです。（リソースと経営陣の支援を確保する方法については、「最初の実践」で説明します。） **第11章: 開発者にインタビューする** 開発者の摩擦を見つける最良の方法は、開発者に尋ねることです。まずは「リスニングツアー」を行いましょう。あなたの目標は、開発者のソフトウェア開発体験を理解することです。ExpeditorsのSVP兼CIOであるコートニー・キスラーが言うように、「彼らの現実を尊重する」ことが大切です。 防御的になったり説明をしたりせずに耳を傾け、彼らの現実を判断する役割ではないことを忘れないでください。好奇心を持ち、必要に応じて詳細を尋ねましょう。役立つ実践をメモすることは大切ですが、解決策を求めることは避けてください。あなたも彼らもまだ全体像を把握していないため、彼らは戦略的なプロダクトオーナーのようには考えていません。良い情報を得るためには、多様な開発者にインタビューする必要があります。私たちのチームや組織との過去の経験を振り返ると、組織のさまざまな部門からの開発者と会うことは常に成果を上げてきました。これにより、異なるチームで異なって見えるツールやプロセス、その他の特異性についての洞察を得ることができます。ツールやプロセスが実際には同じであっても、チームや組織間の違いを特定する手助けになります。 最も効果的にするためには、12〜15人の開発者と話すことをお勧めします（この人数に至った経緯については後ほど説明します）。代表的なサンプルを確保するために、戦略的に計画を立てましょう。経験年数、製品エリア、開発の種類（例：レガシー、モバイル、クラウド、データサイエンス）などの要素を考慮してください。2つの計画リストを作成しましょう： 1. 重要な人口統計。 例えば、勤務場所（対面、リモート、ハイブリッド）や経験レベル（ジュニアまたはシニア開発者）についてです。2. 開発者が働く業務の種類や組織の分野。これらのリストは、インタビューの範囲を把握し、誰と話したかを追跡するのに役立ちます。以下はその一例です。 ここでいくつかのことに気付くでしょう。まず、開発者は複数の人口統計カテゴリに同時に属することができます。例えば、最近入社したシニア開発者は、「シニア開発者」（経験レベルのカテゴリ）と「新入社員」（在籍期間のカテゴリ）の両方を表すことになります。しかし、各カテゴリ内では、次元は相互に排他的です。つまり、同時に「ジュニア開発者」と「シニア開発者」であることはできません。この分類は、誰と話しているのか、そして同じくらい重要なことに、誰と話していないのかを把握するのに役立ちます。上の表を見ると、新入社員と長期勤務の社員の間で比較的バランスが取れていることがわかりますが、プラットフォームやレガシーチームのジュニア開発者とのインタビューが予定されていないこともわかります。これは意図的な場合（例えば、レガシーチームにはジュニア開発者がいないかもしれません）や、単なる見落としである可能性もあります。この可視化を持つことで、そのギャップを見つけ出し、不完全なデータに基づいて決定を下す前に修正することができます。また、「過小評価されている」という列を含めたことにも気付くかもしれません。私たちの経験と研究によれば、過小評価されている開発者はしばしば異なる課題に直面しています。これらの異なる経験は、企業文化や無意識のバイアスによるものである可能性がありますが、選択マップにこれを含めることは有益です。研究によれば、技術分野で過小評価されているグループを支援するためにソフトウェア開発を改善することは、全ての人にとっての開発を向上させることがわかっています。 開発者に、あなたと話すことが彼らの時間を有効に使うことだと知らせましょう。自己紹介と自分の仕事についての短いメモを送り、30分の短いミーティングをお願いすることで、成功への準備を整えることができます。チームや組織文化によって、これらのメモはメールまたはチャットメッセージのいずれかになります。（例のテンプレートについてはステップ1のワークブックを参照してください。）インタビューの合間には、各ミーティングからのメモを整理するためのバッファ時間を確保してください。ただし、この追加の時間はあくまであなたのためのものであり、開発者の時間を尊重することを忘れないでください。強い開発者体験を構築することは、開発者の信頼を得ることから始まります。開発者は、あなたを信頼している場合にのみ、正直な経験を共有してくれます。そして、その信頼を築くのは最初のやり取りから始まります。 多くの開発者は、職場環境についての懸念を繰り返し提起してきましたが、それが無視されたり軽視されたりしてきました。この歴史から、彼らに本当に耳を傾け、行動する準備があることを示すことが重要です。信頼を築くための方法は以下の通りです： + 率先して行動する。自分自身のフラストレーションや学びの瞬間を共有し、脆弱性を見せましょう。信頼は双方向のものである必要があります。 - 敬意を示す。彼らの時間を尊重し、彼らの仕事や専門知識、あなたと共有してくれる洞察に感謝の意を示しましょう。積極的に耳を傾けることが大切です。 過去と現在について透明性を持ちましょう。組織がどのように不足していたのかを認め、現在の課題について率直に話すことが重要です。誠実さは、本当に変化を求めていることを示します。約束を守りましょう。何かをフォローアップすると言ったら、必ず実行してください。コミットメントを注意深く追跡し、進捗が遅いときでも更新情報を提供しましょう。厳しいフィードバックを受け取ったとき—必ずそうなるでしょう—このリスニングツアーを始めた理由を思い出してください。反応する前に一呼吸おき、より深い問題を理解するために質問をし、防御するのではなく学ぶことに焦点を当てましょう。あなたの目標は、開発者の経験を理解し、組織全体でのコミュニケーションを促進することです。最も重要なのは、開発者の現実を尊重することです。開発者の視点は、開発システム、ツール、プロセスに何ヶ月、何年も携わってきた結果形成されており、彼らのストーリーや洞察は、見落としがちな領域を指摘してくれることが多いです。また、フィードバックや関与の機会を作ることも大切です。あなたが会う開発者は、会議の後に何かを思いつくかもしれませんし、リスニングツアーに参加していない開発者も、自分の不満や改善のアイデアを共有したり、改善活動に協力したいと考えるかもしれません。この段階では、軽く実施しやすく、見つけやすいものにしましょう。私たちは、チームがGoogleフォームや社内ウィキの共有ドキュメントを利用するのを見てきました。インタビュー中は、あなたが聞いて学ぶためにここにいることを伝えましょう。成功するインタビューの一般的なフォーマットは次の通りです。 まず、自分自身と会議の目的を簡単に紹介し、聞いて学ぶためにここにいることを伝えます。彼らについての基本情報を尋ねましょう：経験年数、会社にどれくらい在籍しているか、どのチームで働いているか。理論的にはこれを既に知っているかもしれませんが、確認することは有益です。彼らの仕事について3〜5の質問をします。具体的な文脈を提供することが役立ちます（例：「昨日の一日を考えてみてください」や「新しいクラウドインスタンスをプロビジョニングした最後の時を考えてみてください」）。ここから、彼らのワークフローや、ツールやシステムの好きな点、仕事をする上での困難な点について尋ねることができます。最後に、彼らの時間に感謝し、他に共有したいことがあるか尋ねましょう。インタビューが終わったら、あなたの発見をまとめたものを作成し、それを彼らとリーダーシップに共有することを伝えます。 開発者にインタビューする際のいくつかのヒントです。もし開発者がネガティブなフィードバックしか持っていない場合、無理に押し付けないでください！これは彼らの時間であり、組織の改善の大きな機会を浮き彫りにするための機会を利用しているかもしれません。インタビュー中は以下の点に注意しましょう： + 簡単に「はい」や「いいえ」で答えられないオープンエンドの質問を使う。 + 積極的に聞く。 + 一般的な傾向ではなく、具体的な例を求める。 + 明確化のための質問をする。 + 説明や解決策を提供しない。 誘導的な質問は避けましょう（例：「Tool Xが遅いから使わないのですか？」）。ステップ1のワークブックには、インタビューのテンプレートとメモ取りのテンプレートが含まれています。そこには、タイミング、質問、ヒントが記載されています。同じ問題を繰り返し聞くようになったら、十分なインタビューを行った証拠です。これを「飽和」と呼びます。通常、12〜15回のインタビューで飽和が見られますが、早い段階で明確なパターンが見つかれば、7回未満で済むこともありますし、新しい情報が継続的に得られる場合は、もっと多くのインタビューが必要になることもあります。 第12章 学んだことを統合する インタビューを有益な洞察に変えましょう。インタビュー中にラベルを特定し始めることが重要です。リサーチインタビューを行う中で、会話の中での類似点やパターンに自然と気づくようになります。これらをインタビューのメモと一緒に記録するのは良いアイデアです。この勢いを利用して、すべての予定されたインタビューを完了する前に、インタビューの中で共通するパターンをメモしておきましょう（これはラベリングやタグ付けに似ています）。各インタビューテンプレートには、「セットアップ時間の延長」、「プロセスの混乱」、「ドキュメントの欠如」、「ワークフローの中断」などの注目すべきテーマを特定してください。技術だけが摩擦の原因ではないことを忘れないでください。金曜日にデプロイすることへのためらいや、レガシーコードのリファクタリングに対する抵抗など、プロセスや文化について学んだことも重要です。チーム間で現れる品質ゲートや信頼性の懸念に特に注意を払いましょう。これらはしばしば広範な影響を持ちます。これらの観察結果を、すべてのインタビューのテーマをまとめるための主要なトラッキングドキュメント（ワークブックに含まれています）に転記してください。統合されたテーマリストを作成するにつれて、パターンがますます明確になっていきます。開発者のグループに影響を与える課題と、特定のチームや技術環境に影響を与える課題を認識し始めるでしょう。この分析は、組織の痛点や異なる問題間の潜在的な関連性を自然に浮き彫りにします。 理解が深まるにつれて進化する柔軟なフレームワークを構築しましょう。最初は広いカテゴリーから始め、インタビューを通じて学ぶにつれて徐々に具体的な分類に洗練させることができます。または、より詳細なラベルから始め、それらを関連するテーマにグループ化することもできます。このアプローチは、分析が適応可能でありながら、参加者の経験を正確に表す洞察に向かって徐々に構築されることを保証します。AIツールはインタビューのデータからパターンやカテゴリーを迅速に特定できますが、これは多くのチームが効果的に使用している完全に妥当なアプローチです。しかし、データを手作業で処理すること、たとえAIを分析の補助に使ったとしても、貴重なものを得ることができます。それは、人々が実際に何を言っているのかを直感的に感じ取ることです。このハンズオンの関与は、微妙なニュアンスや感情的な含意、すぐには明らかでない関連性を捉えるのに役立ちます。 両方のアプローチにはそれぞれの利点がありますので、あなたの目標やタイムライン、フィードバックをどれだけ深く内面化する必要があるかに基づいて選択してください。これらのテーマとそれを裏付ける証拠をシンプルな文書にまとめましょう。各テーマについては、問題の明確な説明（定義としても機能するもの）を記述し、会話からの代表的な引用を用いてサポートします。各問題がどれほど広範囲にわたるかを記録してください—それは組織全体に影響を与えているのか、それとも特定のチームだけなのかを確認します。また、課題やテーマが一緒に発生するパターンにも注意を払いましょう。潜在的な影響や解決の難しさについての初期の考えを含めますが、この段階では優先順位をつけたり、解決策に飛びついたりしないようにしましょう。この統合は、いくつかの目的を果たします。散発的なフィードバックを構造化された理解に変え、ステップ2で特定する優先事項の基盤を作り、共有するフィードバックの初期のアウトラインと説明を提供します。ステップ1のワークブックにはサンプルテンプレートがありますので、参考にしてください。 ノートを再度見直しましょう。全く異なる体験をした開発者の意見を軽視しないでください—例外的な意見は、他の人が共有することに抵抗を感じていた未解決のニーズや問題を明らかにすることがよくあります。ノートを再確認し、開発者が実際にあなたに伝えたことと、あなた自身の経験に基づいて導き出した結論を分けて考えましょう。あなたを不快にさせる反応や、開発者の摩擦についての知識に挑戦するような意見に注意を払いましょう。表面的なメモを超えて、行動やコメントの背後にある「なぜ」を探ります。 統合から異なる要約を準備し、それぞれの要約は主要な聴衆を対象にします（通常は2つですが、もっと多い場合もあります）。リーダーシップ向けには、ビジネスへの影響が最も大きい主要なテーマに焦点を当てます。各摩擦点のコスト（時間、品質、開発者の満足度）を示す具体的な例を含めます。さらに調査すべき初期の領域を提案しますが、この要約は簡潔でビジネスに焦点を当てたものにし、理想的には2ページ以内に収めます。異なる聴衆に向けたフレーミングにはAIツールが役立つことがあります。 また、開発者とあなたの発見を共有することも重要です。これにより、今後の取り組みに参加する意欲を高めることができます。チーム間で聞いた主要なテーマを認識する要約を作成し、具体的なコミットメントをせずに次のステップを概説し、率直なフィードバックに対する感謝の意を表します。「ループを閉じる」ことで、彼らのフィードバックを理解したことを確認し、彼らの意見がプロセスを推進していることを示します。 既存のデータがあれば、それを活用しましょう。インタビューと並行して、最近の調査、退職面談、チームの振り返りなど、既存の（かつ簡単に入手できる）情報をレビューすることで、持続的な問題が明らかになることがよくあります。Slackチャンネルも役立ちます。ディスカッションを確認したり、重要な人物を特定したりするのに便利です（例えば、1人の人がすべての質問に答えている場合、その人は複数の領域に関する素晴らしい洞察を持っているかもしれません）。 テーマを別々に探すことも、インタビューで明らかにしたテーマに含めることもできます。第13章では、開発者のワークフロー、ツール、そして摩擦を可視化する方法について説明します。 まず、開発者がコードを書くために行うステップをリストアップしてください。開発者にインタビューを行う際には、彼らが仕事をするために取るステップに耳を傾け、ワークフローのすべてのステップを包括的にリスト化します。これには、環境の設定、コードの記述とデバッグ、プルリクエストのレビュー、テストの実行、デプロイが含まれます。また、セキュリティレビューやドキュメント作成など、組織特有のタスクも含めてください。同様に、各ステップで使用されるすべてのツールと技術も記録します。IDE、バージョン管理システム、CI/CDプラットフォーム、テストフレームワーク、モニタリングソリューション、カスタムまたは内部ツールなどです。開発者がAIを使用している場所や、AIがソフトウェア開発のワークフローに組み込まれている場所も記録してください。摩擦が特定のツールの組み合わせや設定で発生することが多いため、関連するバージョンや構成について具体的に記載することが重要です。些細に思えることでもすべてをリストアップしてください。摩擦が潜んでいる場所は予測できないからです。例えば、環境変数の設定や内部サービスへの認証といった一見小さなステップが、実は大きな痛点になることがあります。これらのツール、摩擦ポイント、そしてツールをソフトウェア開発の各ステージごとにリスト化することが役立つかもしれません。この点については、ステップ1のワークブックに例となるワークシートを含めています。 専門的な開発者のワークフローも忘れないでください。コアとなるソフトウェア開発のワークフローはほとんどの開発者に適用されますが、一部の役割には独自の摩擦ポイントを生む追加のステップがあります。例えば、機械学習（ML）エンジニアは以下のような作業が必要です： - データセットの取得、クリーンアップ、バージョン管理 - 異なるモデルやハイパーパラメータでの実験 - 専用ハードウェア（GPU、TPU）でのモデルのトレーニング - 実験結果やモデルのパフォーマンスの追跡 - 推論エンドポイントへのモデルのデプロイ - モデルのドリフトやパフォーマンスの劣化の監視 同様に、モバイル開発者はデバイスのプロビジョニングやアプリストアへの提出プロセスを持つかもしれませんし、データエンジニアはパイプラインのオーケストレーションやデータ品質の検証ステップを持つかもしれません。ワークフローをマッピングする際には、これらの役割特有の活動も含めるようにしてください。GPUの利用可能性を待つことや大規模データセットの管理といった専門的なワークフローにおける摩擦は、従来の開発ボトルネックと同じくらい影響力があります。 インタビューの最後には、典型的な開発者のワークフローについて良いアイデアを持っているはずです。もしまだ詳細が必要であれば、チームの他のメンバーに話を聞いたり、数人の開発者にフォローアップすることができます。これらの議論はインタビューと似たような形になるでしょう。具体的で最近のシナリオに基づいて質問を行ってください。例えば、「最後に一日の始まりを思い出してください。あなたのプロセスを教えてもらえますか？」や「新しいラップトップを設定したのはいつですか？どのようなステップを踏みましたか？」といった質問です。これらの会話は、ワークフローや潜在的な痛点について貴重な洞察を明らかにすることができます。 リストをワークフローダイアグラムに変換することを検討してみてください。これらはプロセスを可視化し、特に測定が難しいステップ間の摩擦を見つけるのに役立ちます。また、チームが協力して問題を解消できる領域を明らかにすることもできます。ステップ1のワークブックには、いくつかのチェックリストの例を含めています。最後に、これらのリストやダイアグラムを使ってステークホルダーとコミュニケーションを図りましょう。これらは、開発者が直面する複雑さを示すための強力なツールであり、DevEx改善イニシアティブへの支持を得るのに役立ちます。 SiriusXMのビジョンファーストのアプローチ： 「現状ではなく、理想を描く」 SiriusXMのプラットフォームチームは、開発者体験を改善したいと考え、従来のアプローチを逆転させました。現在のワークフローをマッピングして痛点を特定するのではなく、理想的な体験から逆算して作業を進めました。彼らは、オンボーディングからデプロイメント、運用まで、完璧な開発者の旅がどのようなものであるべきかを示す包括的なユーザーガイドを作成しました。チームは、さまざまな分野のプラットフォームオーナーとの作業セッションを数回行い、その後、実際のユーザーにガイドを見せて改良を重ねました。その結果、「テクノロジストの旅」という、消費者向け製品のためにしばしば作成される従来のユーザージャーニーを基にした開発者向けのバージョンが生まれました。この旅は、ソフトウェア開発ライフサイクル（作成、反復、テスト、デプロイ）、運用タスク（スケーリング、フェイルオーバー、可観測性）、オンボーディングプロセス、さらにはソフトウェアの引退にまで及びます。このエンドツーエンドのワークフローを可視化することで、SiriusXMは現在の現実と理想的な体験との間にある具体的なギャップを特定し、それを埋めるためのターゲットプロジェクトを立ち上げることができました。 第14章 ステークホルダーを理解する あなたが持っているステークホルダーの数に驚くかもしれません。開発者とワークフローについて話している間に、DevEx改善イニシアティブに関わるすべてのステークホルダーを特定し理解することも同様に重要です。早い段階で包括的なステークホルダーマップを作成することで、コミュニケーションを調整し、適切な期待を設定するのに役立ちます。誰かがステークホルダーに該当するかどうか不明な場合は、シリコンバレー・プロダクトグループが使用する「拒否権テスト」を適用してみてください。もしその人があなたのプロジェクトに対して拒否権を持っているか、プロジェクトの立ち上げを止めることができるなら、その人は関与すべきステークホルダーです。 まず、すべての潜在的なステークホルダーグループをリストアップしましょう。これには以下が含まれるかもしれません： - エンジニアリングチーム：改善の影響を直接受ける開発者、テックリード、エンジニアリングマネージャー。 - 補助機能：SRE、データサイエンティスト、カスタマーサクセスエンジニアは製品エンジニアではないかもしれませんが、あなたの調査や解決策は彼らの仕事に影響を与える可能性があります。 - リーダーシップ：CTO、エンジニアリングVP、リソースを承認する他の意思決定者。 - 隣接機能：開発とインターフェースを持つプロダクトマネージャー、デザイナー、QA専門家。 サポート機能：人事 人事の専門家は、離職率の指標に関心を持ち、財務チームのメンバーはコストを監視し、セキュリティチームはコンプライアンスの側面を気にしています。 外部グループ：開発者の生産性向上から恩恵を受ける可能性のある顧客やパートナーチーム。 各ステークホルダーグループについて、主要な連絡先や推進者、DevEx（開発者エクスペリエンス）に対する関心、好ましいコミュニケーションチャネルなどを文書化してください。例えば、リーダーは進捗状況やビジネスへの影響についての更新を求めることが多く、開発者は変更が日常業務にどのように影響するかを理解する必要があります。人事は、あなたの取り組みが離職率の指標を改善する可能性について関心を持つかもしれませんし、財務は人員要件やクラウド支出に焦点を当てます。ステップ1のワークブックには、各グループの関心度、DevExの概念への親しみ、あなたの取り組みに対する一般的な支持を文書化するためのステークホルダーマトリックスのテンプレートが含まれています。このマッピングは、あなたの作業や結果についてのコミュニケーションを準備する際に非常に役立ちます。これはステップ5で詳しく説明します。 第15章 学んだことを共有する 学んだことを整理したら、その結果を必ず共有してください。共有する前に、数日間かけて整理を洗練させることをお勧めします。信頼できる同僚からフィードバックをもらい、テーマが期待した内容ではなく、実際に聞いたことを正確に反映しているか確認してください。この慎重な分析は、聞くことと行動の間の架け橋を作り、ステップ2で探求する集中した改善に向けての準備を整えます。 まずはリーダーシップに結果を共有します：重要なリーダーシップのステークホルダーにエグゼクティブサマリーを最初に送信します。これにより、リーダーシップの整合性と組織的な質問への準備が確保されます。組織内で共有が一般的であれば、開発者のサマリーも含めてください。これらは初期の議論から得られた結果であり、まだ組織や重要な問題についての理解を深めている最中であることを強調します。フィードバックや議論に基づいて開発者のサマリーを修正・洗練する準備をしておいてください。 次に、開発者に連絡を取ります。リーダーシップとの議論や文書の更新後、適切なチャネルを通じて開発者のサマリーを配布します。これらの結果を透明に共有することで、開発チームとの信頼関係が築かれ、フィードバックが反映され、行動に移されることで、改善プロセスに対する共同所有感が生まれます。フィードバックを反映した開発者は、今後の取り組みに建設的に関与する可能性が高くなります。開発者へのメッセージは、ROIや価値の議論を最小限に抑え、参加してくれた人々への感謝を強調し、まだ学び続けていることを伝えるように工夫することをお勧めします。人事や組織のリーダーと協力して、すべてのエンジニアへの直接メールか、エンジニアリングマネージャーを通じての伝達など、最適なコミュニケーションの方法を決定してください。 サマリーを共有した後は、継続的な対話に備えておいてください。開発者は、あなたが見逃した追加の経験を共有したり、次のステップについて質問したりするかもしれません。 これらの議論にはオープンな姿勢を保ちつつ、早急なコミットメントを避けるよう注意してください。アクションプランは、リソースや組織の優先事項、既存の取り組みに基づいて進化する可能性が高いです。この初期のコミュニケーションは、ステップ5で取り上げるより包括的なコミュニケーション戦略の基盤を築くものです。ステークホルダーの支持を得るために初期の発見を伝えることが重要です。Minh PhamとTitus StoneがIbottaのエンジニアリングリーダーシップチームで開発者の体験に関する洞察を共有し始めたとき、彼らは初期の発見の伝え方がステークホルダーの信頼を左右することをすぐに実感しました。彼らの初期のメトリクス重視のプレゼンテーションは反響を呼ばず、「PTSDが私に飛び込んできた」とMinhは振り返ります。しかし、その失敗から学び、継続的なコミュニケーション戦略を適応させることで、彼らは今や繁栄しているDevExチームを確保し、維持するために必要な信頼性を築くことができました。彼らは影響を過剰に売り込むのではなく、初期段階について透明性を持ちながら定期的な接点を維持することを学びました。「私たちは常にエレベーターピッチやボードスライドを更新しています」とMinhは説明します。「リーダーシップに対して、まだ進展があることを常に思い出させる必要があります。」このアプローチは、正直な期待を持ちつつ、月次のチェックインと進化するメッセージを組み合わせることで、信頼性を維持しながら支持を築くのに役立ちました。リーダーシップは、現実的な枠組みと一度きりのプレゼンテーションではなく、継続的なコミュニケーションへのコミットメントの両方を評価しました。 あなたがリスニングツアーを終え、組織全体の開発者から初期の洞察を集めた今、痛点や機会に関する豊富な情報を持っています。しかし、改善の可能性が多くある中で、どこから始めるべきでしょうか？答えは、すべてを一度に解決しようとしないことです。次の章では、モメンタムを築き、DevEx改善イニシアチブの信頼性を確立するための小さくて高い影響力のある勝利を特定し、実行する方法を示します。 ステップ2 小さく始めて、迅速な勝利を得る あなたは開発者と直接話し合い、彼らの日常のフラストレーションについて聞き、初期の要約を組織に共有しました。これらの洞察をもとに、あなたは学んだことを評価し、行動を起こす準備が整いました。すべての問題を一度に解決しようとするのではなく、あなたのアプローチを検証し、迅速に価値を示すターゲットを絞った改善に焦点を当ててください。私たちのルーブリックを使用して潜在的な迅速な勝利を評価する際には、チームのエンゲージメントや協力の機会を測る基準に特に注意を払ってください。このアプローチは、即座の結果をもたらすだけでなく、将来の取り組みの基盤を強化します。このセクションでは、信頼を築き、モメンタムを生み出す高影響の迅速な勝利を特定、優先順位付け、実行する方法を示します。 第16章 適切なプロジェクトを選ぶ DevEx改善イニシアチブを開始する際には、あなたのアプローチを検証し、懐疑的な人々を支持者に変えるための目に見える勝利が必要です。 面接中に 合成の過程で、いくつかの候補プロジェクトが潜在的な出発点として浮かび上がったことでしょう。初期プロジェクトは重要です。なぜなら、早期の成功が能力を示し、ステークホルダーの信頼を築くと同時に、あなたのDevEx全体のストーリーの基盤を形成するからです。選択肢の中には明らかに見えるものもありますが、異なる基準を考慮しながら機会を慎重に評価することが重要です。 DevExプロジェクトのためのQuick RICEの活用。RICEフレームワーク（Reach、Impact、Confidence、Effort）は、分析の迷宮に陥ることなく機会を評価するシンプルな方法を提供します。RICEを使うことで、成功の可能性が高いプロジェクトを見つけ出し、高いリーチ、高いインパクト、高い信頼を持ちながら、労力を低く抑えることができます。初期プロジェクトの選定においては、これを「Quick RICE」または「gutcheck RICE」と考えてください。つまり、有望な候補を特定するために迅速な評価を行い、詳細な分析は後回しにします。その深掘りは、より多くのデータが得られた後に行います。 リーチ：どれだけの開発者がこの問題を感じていますか？広範なリーチに焦点を当てましょう。少数の開発者の深い問題を解決するのではなく、多くの開発者に利益をもたらす改善を選びます。頻度も考慮してください。開発者に頻繁に影響を与える摩擦のある領域（例：日常的または1日に複数回）は、初期プロジェクトの優れた候補です。 インパクト：開発者はすぐに改善を実感できますか？目に見えるインパクトを目指しましょう。開発者がすぐに感じる改善を選ぶことで、後で価値を証明する必要が減ります。例：自動依存関係チェックと標準化されたPRテンプレートを実装し、コードレビューサイクルを3日から1日に短縮することです。開発者が認識している問題に焦点を当てましょう。開発者がすでに知っていて、個人的に感じている問題をターゲットにします。根本的な原因に取り組むのは魅力的ですが、開発者やそのマネージャーは進捗を見て感じたいと思っています。これらの成功は信頼性を築き、自然にリーダーシップの注目を集めます。 信頼性：この成功を実現できますか？進捗を示す明確なマイルストーンを探しましょう。ステークホルダーが追跡できる可視的なチェックポイントを簡単に特定できるイニシアチブを選びます。マイルストーンは、段階的な成功を示し、勢いを維持し、何かがうまくいっていないことを過度に時間を投資する前に特定するのに役立ちます。測定可能なプロジェクトを選びましょう。進捗と価値が既存のまたは簡単に取得できる指標を通じて測定できるプロジェクトを選びます。このアプローチは、価値を提供することとその存在を証明することの二重の負担を排除し、チームが問題解決に集中できるようにします。 労力：どれくらい早く結果を示せますか？手の届きやすい問題を見つけましょう。厄介だが修正可能な問題（これを「ペーパー・カット」と呼ぶ人もいます）を探します。一般的な例には、繰り返しのタスクの自動化、不安定なテストの修正、難しいUIの改善、開発環境へのアクセスの簡素化などがあります。あなたの状況によっては、いくつかの問題が含まれるかもしれません。 これらのプロジェクトのいくつかは、より多くの作業を必要とするかもしれませんので、評価を行い、数週間（あるいは数ヶ月）以内に対処できるものを探してください。中程度の複雑さを目指しましょう。意味のある価値を提供できる程度の複雑さを持ちながら、行き詰まるリスクがないプロジェクトを選んでください。これらの「ゴルディロックス」な取り組み、例えば不安定なテストスイートの修正、監視ダッシュボードの改善、データ移行の完了などは、能力を示しつつ勢いを維持するものです。単なる忙しい作業のように感じる些細な変更や、完了までに四半期かかる可能性のある野心的なリファクタリングは避けましょう。タイムラインも考慮してください。初期のプロジェクトは3ヶ月以内に結果を示すべきであり、後の取り組みは6ヶ月から9ヶ月ごとに目に見えるマイルストーンを持つべきです。例えば、重要な再アーキテクチャを必要とする初期プロジェクトは避けるべきです。これらは通常、かなりの時間を要し、完了するまで目に見える進捗がほとんどありません。 Quick RICEを活用する。インタビューの合成から候補プロジェクトを評価する際には： 1. 各プロジェクトをRICEの各要素についてシンプルなスケール（高・中・低）で評価します。 2. パターンを探します。リーチとインパクトが高く、努力が中または低のプロジェクトはしばしば成功します。 3. 直感を信じましょう。良いスコアにもかかわらず何かが違和感を感じる場合は、さらに掘り下げてください。 4. 組み合わせを考慮します。時には、2つの小さなプロジェクトを組み合わせることで、大きな1つのプロジェクトよりも大きな影響を生むことがあります。 目標は数学的な精度ではなく、明確さです。このチェックリストアプローチは、直感を防御可能な決定に変え、隠れた仮定を明らかにし、公平な比較ポイントを作成します。 Quick RICEの実例を見てみましょう。インタビューで浮かび上がった3つの候補プロジェクトがあるとします：不安定なテスト自動化、効率的なコードレビュープロセス、監視ダッシュボードです。各RICEの次元について迅速かつ定性的な評価を行うことができます。 | プロジェクト | リーチ | インパクト | 確信 | 努力 | |----------------------------------|--------|------------|------|------| | 不安定なテスト自動化 | 高 | 高 | 中 | 高 | | 効率的なコードレビュープロセス | 高 | 高 | 高 | 低 | | 監視ダッシュボード | 中 | 中 | 高 | 中 | Quick RICEは、コードレビュープロセスから始めることを提案します。広範な影響、高い確信、低い努力で迅速な成果が得られます。テスト自動化は、信頼を築き、長期的なタイムラインに投資できるようになったときに取っておきましょう。 評価を明確さに変える。Quick RICEを使用することで、直感を明確な決定に変え、隠れた仮定を明らかにし、公平な比較ポイントを作成します。また、基準により、広範な影響や達成可能な範囲のために、広範なデータ収集なしで行動を提唱しやすくなります。このフレームワークを適用することで、プロジェクトの進捗を測定する能力について掘り下げることを促されるかもしれません。たとえば、既存のメトリクスや簡単に取得できるメトリクスで進捗を測定する能力が不明確な場合です。この演習は、あなたの技術スタックと組織の暗黙のルールの両方を知っている誰かとチームを組むことをお勧めします。彼らの視点が、あなたが見逃すかもしれない盲点を見つけてくれるでしょう。あなたのDevExの突破口は、ツールではなくプロセスかもしれません。 テクノロジーに精通した人々は新しいツールを好みますが、時には最も効果的な開発者体験（DevEx）の改善は、ツールよりもプロセスの改善から生まれることがあります。プロセスの改善は、AIを活用したソリューションの候補としても非常に有効です。プロセスを最適化する際は、摩擦を減らし、勢いをつけるために、まずは迅速に成果が得られる小さな改善から始めると良いでしょう。完全な自動化が最終目標であっても、小さな変更が開発者の生産性や満足度を大きく向上させることがあります。インタビューの分析では、以下のような問題点が浮かび上がるでしょう： - 複雑または不明瞭な承認プロセス - 複数の場所に散在するドキュメント - 孤立したチームが使用するカスタムツール - 一貫性のない基準や期待 - 決定や更新に対する限られた可視性 開発者の痛点に直接対処する高インパクトなプロセス改善に焦点を当てましょう。承認ワークフローの簡素化や冗長なステップの削除を検討し、開発者と協力して彼らのニーズに合った明確なコードレビュー基準を確立します。また、デモやニュースレターを通じて定期的な知識共有セッションを開催し、可視性を向上させ、ドキュメントやリソースのための中央ハブを作成します。これらの変更は、最小限の技術的投資で実現できることが多く、重要な価値を提供します。ステップ2のワークブックには、ステップ4で探るフレームワークの簡易版であるクイックRICEルーブリックがあります。これらの基準を確認し、最良の結果を得るために特定の環境に適応させてください。 文化から始める：MongoDBのポストモーテム戦略。タラ・ヘルナンデスがMongoDBに開発者生産性のVPとして参加した際、彼女は明らかな技術的改善—より速いビルド、より良いツール、効率的なデプロイメント—から始めることもできました。しかし、彼女はリスニングツアーを実施した後、従来のSREやオペレーションチームの枠を超えて、開発者生産性チームにポストモーテムを導入するという独自の選択をしました。ポストモーテムは本番インシデントに対する標準的な手法ですが、彼女はそれを開発作業全体に広げました。彼女のチーム内での文化的変化は即座に現れ、開発者たちは失敗を恐れるのではなく、積極的な学習文化の一部であることに安心感を持つようになりました。この透明性は、DevProdチームに対する広範なエンジニアリング組織の認識を改善し、他のチームにも同様の実践を採用するよう促しました。組織全体の変革は、CTOが参加し、MongoDBのエンジニアリング組織全体で運用の卓越性を推進したときに訪れました。このリーダーシップの支援は、すでに根付いていた文化的変化をさらに強化しました。教訓として、文化的変化はしばしば個々のチームが新しい実践を示すところから始まりますが、その変化を組織全体に拡大するためにはリーダーシップの支援が不可欠です。 第17章 早期の成果を共有して勢いを得る ステークホルダーと早期の進捗をコミュニケーションし、祝うことで、DevExの展開に向けた勢いを築きましょう。 DevExの展開に向けて勢いをつけるためには、ステークホルダーと初期の進捗を共有し、祝うことが重要です。この章での活動は、基本的に変革管理に関するものであり、組織が新しい働き方を受け入れる手助けをします。（包括的な変革管理戦略については、第二の実践で詳しく掘り下げます。） 失敗を恐れず、学びを共有しましょう。進捗を妨げる障害に直面することもあります。依存関係が進行を妨げたり、ステークホルダーが変化に抵抗したり、指標が改善を示さないこともあるでしょう。そうなった場合は、透明性を持って対応し、うまくいかなかったことを共有し、迅速に方向転換しましょう。これにより信頼が築かれ、チームが迅速に学ぶ限り、失敗は許容されることが示されます。例えば、あるチームのCIパイプラインの改善では、実際のボトルネックがコードレビューのプロセスにあったため、デプロイ速度の向上が見られませんでした。彼らはレビューの効率化にシフトし、即座に結果を得ることができました。 ここで、指標やマイルストーンが早期にこれらの障害を浮き彫りにし、認識するのに役立ちます。初期の指標は複雑である必要はありません。「デプロイ時間が45分から10分に短縮された」といったシンプルな前後の測定が、問題を迅速に特定するのに役立ちます。失敗したアプローチに何ヶ月も費やさないでください。教訓を文書化し、新しいことに挑戦しましょう。途中での成功を祝うことも重要です。特にインフラやプラットフォームの作業では、「無事であれば良い」という考え方が支配的になりがちで、成功が見過ごされ、問題ばかりが注目されることがあります。小さな成功も認識されるべきです。チームの成果や個々の貢献を目に見える形で祝うことで、参加の価値を強調しましょう。これらの祝賀を定期的なコミュニケーションの一部にしましょう： - チームミーティングでの成功を共有し、具体的な貢献を強調する。 - 可能な限り改善を定量化する（「ビルド時間を30分から5分に短縮しました」と言う方が「ビルドを速くしました」よりも伝わります）。 - 成功を目に見える場所（ウィキ、Slackチャンネル、ニュースレター）に文書化する。 - 上層部に報告する際には、改善をビジネスへの影響に結びつける。 - 個々の貢献や努力に対して感謝の意を示す。 - 成功を次の挑戦への勢いに変える。 定期的な祝賀は、開発者が評価されていると感じ、DevExイニシアティブへの参加から具体的な結果を見られる文化を育むのに役立ちます。 他の人もこの旅に巻き込みましょう。戦略を推進する人であれ、ソリューションを設計する人であれ、あなたのイニシアティブに関わるすべての人を仕事のパートナーとして扱いましょう。クレジットを惜しまず、好奇心を育てましょう。プロセスやインフラの選択について「明らかな」質問を投げかけることで、他の人が言い出せなかった重要な洞察が明らかになることがよくあります。一緒に学ぶことがプロセスの一部であることを明確にし、他の人が自分の質問や観察を声に出すことを奨励しましょう。 改善の最初の機会を特定したら、その結果を各オーディエンスに響く方法で共有しましょう。異なるグループには異なるタイプのコミュニケーションと詳細レベルが必要であることを忘れないでください。 聴衆の既存の言語や用語を使い、新しい概念は戦略的な目的がある場合にのみ導入しましょう。例えば、停滞している取り組みを再起動したり、混乱を解消したり、確立された考え方を変えたりする場合です。潜在的な解決策を議論の出発点として提示し、積極的に意見や協力を求めましょう。開発者に対しては、日々のタスクでの時間短縮や、効率的なワークフロー、摩擦点の削減といった具体的な改善に焦点を当てます。彼らが変化が自分の仕事にどのように直接的に利益をもたらすかを理解すれば、受け入れ、推進する可能性が高まります。優先順位付けのプロセスを共有することで、透明性が信頼を築き、即時の変化が全員に影響しない場合でも賛同を得やすくなります。基準に対するフィードバックにはオープンでいることが重要です。開発者の洞察がアプローチを洗練させる手助けになるかもしれません。 エンジニアリングマネージャーには、チームレベルの成果、例えば生産性の向上やリソースのより良い活用、チーム間のコラボレーションの改善を強調します。これらの変化が彼らのチームにどのように価値を提供するかを理解させる手助けをしましょう。再度、プロセスについて透明性を持つことで信頼を築き、賛同を得ることが重要です。リーダーシップには、ビジネスへの影響を強調します。これには、納期の短縮やエンジニアリングの速度指標、投資収益率が含まれるかもしれません。DevExの改善を組織の目標や優先事項に結びつけましょう。 コミュニケーションチャネルは慎重に選びます。まずリーダーシップと連携して整合性を確保し、その後、Slackやメール、社内ブログなど、組織の好ましいプラットフォームを通じて広く共有します。HRや組織のリーダーと連携して、適切な聴衆に効果的にアプローチしましょう。会話を続けることも大切です。継続的な対話に備え、開発者が見逃した追加の経験を共有したり、次のステップについて質問したりすることがあるかもしれません。これらの議論にはオープンでいる一方で、早急な約束をしないよう注意しましょう。アクションプランは、リソースや組織の優先事項、既存の取り組みに基づいて進化する可能性があることを透明に伝えます。 第18章 一般的な落とし穴を避ける クイックウィンは勢いを築くために不可欠ですが、それを達成する方法も重要です。ヴァン・ビューレンとサッファーストーンは、企業で新しい取り組みを実施している5400人のリーダーを研究しました。彼らの研究は、長期的な成功を損なう可能性のある一般的な落とし穴を明らかにしています。成功したリーダーがこれらの課題をどのように乗り越えているかを見てみましょう。 フィードバックの扱い方。質問されたときに防御的にならないようにしましょう。自分が投資した仕事を守りたいと感じるのは自然ですが、防御的になると対話が途切れてしまいます。代わりに、自分の理論や理由を説明しましょう。これにより、抵抗ではなく理解が生まれます。DevExチームは、自分たちの経験が広範なエンジニアリング組織を代表していると考えがちですが、これは一般的な盲点です。批判を貴重な意見として受け止めましょう。エンジニアはあなたの顧客であり、彼らのフィードバックがより良い解決策を形作ります。好奇心を持ち、早期のフィードバックを求め、聞くことが信頼を築くことを忘れないでください。（フィードバックを集めるためのヒントは第12章のリスニングツアーを参照してください。） チームダイナミクス。解決策を提案する際に過信しないようにしましょう。 チームは似たようなアプローチを試み、隠れた課題に直面しているかもしれません。問題の特定と優先順位付けに注力しましょう。知識と真の好奇心のバランスを取ることが重要です。権限を与えられたチームが、特定した問題に対する解決策を探求できるようにし、リスニングツアーからの洞察を引き続き収集してください。（リスニングツアーでのフィードバック収集に関するヒントは第12章を参照してください。） 意思決定について。孤立して解決策を構築しないでください。迅速な進展を示そうとする最善の意図があっても、DevExチームは異なる意見に対処するのを避けるために一人で作業する罠にはまりがちです。これは特にDevExの取り組みにおいて顕著で、顧客はしばしば正しい解決策について強い意見を持っています。コラボレーションを大切にしましょう。広範なエンジニアリング組織を巻き込む取り組みを選びましょう。個別の迅速な修正は効率的に見えるかもしれませんが、共有の所有権を持つプロジェクトはより良い解決策を生み出し、強い支持を得ることができます。（評価基準についてはワークブックを参照してください。） 実行スタイルについて。エンジニアを細かく管理しないでください。組織全体の権限を与えられたチームが解決策を探求できることを信頼しましょう。最良の取り組みや製品は、リーダーが問題を特定し優先順位を付け、権限を与えられたエンジニアリングチームが解決策を探求するものです。文脈を共有することに投資しましょう。エンジニアが全体像を理解すると、より良い解決策を設計し、情報に基づいた意思決定を行います。これにより、チームの判断に対する信頼も築かれます。更新や決定のための明確なコミュニケーションチャネルを作成してください。（詳細はステップ5で議論します。） 研究によると、最も成功したリーダーは迅速な成果を避けるのではなく、それを受け入れます。彼らの重要な違いは、個々の成果ではなく、チームの能力と共有の成功を築くことに焦点を当てている点です。迅速な成果が信頼性と勢いを築いている間に、開発プロセスの摩擦を特定し対処するためのより体系的なアプローチを発展させる必要があります。DevEx改善イニシアチブがこれらの初期の勝利を超えて成熟するにつれて、データは次にどこに努力を集中させるべきかを判断するためにますます重要になります。次の章では、開発者の摩擦の真の影響を明らかにし、進捗を測定するためのデータの収集と分析方法について探ります。 ステップ3 データを活用して自分のDevEx作業を最適化する 成功したDevEx改善イニシアチブは摩擦を減少させます。次のステップは、データを使用して摩擦を特定し、次に取り組むべき課題を決定することです。迅速な成果はDevExの改善の価値を示し、イニシアチブの勢いを築きました。今こそ、初期の発見を超えて、より包括的で厳密なアプローチに移行する時です。この章では、摩擦ポイントを体系的に特定し、改善の優先順位を付け、時間をかけて進捗を追跡するためにデータを収集、分析、活用する方法を探ります。まだ解決策に急がないでください（それについてはステップ7で触れます）。摩擦は、開発ツール、ワークフロー、プロセス、セキュリティ対策、コンプライアンス要件など、さまざまな領域に潜んでいます。 AIを開発プロセスに取り入れているチームにとって、体系的なデータ収集は特に重要です。AIツールは新たな変数や潜在的な摩擦点をもたらし、適切な測定がなければそれらを検出するのが難しくなることがあります。あなたの課題は、これらの痛点を明らかにし、それを体系的に優先順位付けすることです。 ### 第19章 データ基盤の確立 改善の取り組みを優先順位付けするのに苦労している場合、開発者とのインタビューだけでは不十分です。リスニングツアーやインタビューで特定された問題に取り組んだ後、複数の改善の可能性がある状況に直面することがあるでしょう。このような状況では優先順位を付けるのが難しく、より多くのデータが必要です。開発者のフィードバックは非常に重要であり、追加のデータを得るための優れた方法はアンケートです。アンケートは、多くの情報を体系的に収集し、より簡単に定量化できる方法を提供します。これにより、進捗を測定し、作業を評価し、責任を確保することができます。 ### リスニングツアーを忘れずに まだリスニングツアーを実施していない場合（既存のDevEx改善プロジェクトに参加したためや、主要な問題がすでに明確だったためなど）、今すぐ行ってください。開発者との数回の会話でも、あなたの作業を具体化し、貴重な洞察を提供し、説得力のあるストーリーを作成するのに役立ちます。 考慮すべきデータにはいくつかの種類があり、重複する部分もあります。 - **定性的データ** 定性的データは記述的で、インタビューのトランスクリプトやアンケートの自由回答などが含まれます。ステップ1でのリスニングツアーが最初の定性的データセットを提供し、それを基にさらに構築していきます。 - **定量的データ** 定量的データは数値的で、計算可能な形で表現されます。例えば、1-5のアンケートスケールでの回答や、バージョン管理システムの使用に関する統計などです。また、自己報告データとシステムデータについても触れます。自己報告データとシステムデータは、どちらも定性的または定量的であり得ます。 - **自己報告データ** 自己報告データは、人々の認識や経験から得られます。これは定性的（インタビューや自由回答など）または定量的（1-5スケールのアンケート回答など）である可能性があります。 - **システムデータ** システムデータは外部から観察・測定できるもので、客観的データとも呼ばれます。通常は定量的（コミット数やPRのターンアラウンドタイムなど）ですが、定性的（エラーメッセージなど）であることもあります。 自己報告データとシステムデータは、DevEx改善イニシアチブにおいて補完的かつ重要な役割を果たします。それぞれに強みと限界があります。アンケートとシステムデータは戦略的なパートナーであり、それぞれ独自の強みを持っています。アンケートは未知の摩擦点を特定し、満足度の指標を提供し、ツール間の引き継ぎ問題を把握し、心理的要因を測定するのに優れています。 一方で、システムデータは、計測されたワークフローの正確な定量化、時間の経過に伴う改善の傾向、ワークフローステップの客観的な測定、詳細なシステムパフォーマンスメトリクスの提供に優れています。これらの強みは、各種データの限界を補うのに役立ちます。システムデータは、既存のテレメトリの範囲外の情報や、AIの利用やその利点といった新たで複雑な概念を捉えることはできません。また、システムデータは、満足度や燃え尽き症候群といった心理的要因を捉えることもできません。一方、調査データは、信頼性のある精度を捉えることができず、継続的に収集することも難しいです。最も成功しているDevEx（開発者体験）イニシアチブは、自己報告データとシステムデータの両方を活用しています。調査は、何を測定するかを特定するために利用され（DORAメトリクスなどの基本的な事実データを求めることもあります）、システムデータは、どれだけ改善されたかを正確に追跡するために使用されます。また、自己報告データとシステムデータの両方を用いて、1) どのイニシアチブが最も影響力があるか、2) システムデータに存在するギャップで、最も重要なものは何かを決定します。あなたの作業が拡大するにつれて（数百人の開発者に対して、あるいはシステム全体にわたって）、効果的に優先順位を付け、進捗を追跡するためには定量的データが必要です。インタビューから得られるストーリーは、小規模なグループや初期のシグナルを得るのには適していますが、数値は問題を精密に分析し、ランク付けすることを可能にします。まずはシンプルに始めましょう。スケールやランク付けされた回答を含む基本的な調査でも、生産性に最も悪影響を与える技術やプロセスを明らかにすることができます。その後、システムテレメトリを追加することで、摩擦点のコストや改善の影響を時間の経過とともに示す、さらに豊かな洞察を得ることができます。 第20章 既存のデータを特定し、活用する ほとんどの組織には、開発者体験に関する貴重な洞察を提供できる未活用のメトリクスがあります。新しい計測に時間とリソースを投資する前に、すでに利用可能なデータソースを徹底的に棚卸ししてください。ただし、重要な注意点があります。もし誰もこれらのメトリクスを適切な所有権と品質管理を伴うデータプロダクトとして扱っていなければ、そのデータはほぼエラーだらけです。したがって、既存のメトリクスには健全な懐疑心を持って接してください。既存のデータを特定する際には、開発者のジャーニーマッピングを利用してデータソースを指し示すことができます。例えば： - 開発活動：バージョン管理メトリクス、プルリクエストのパターン、コードレビューの時間、AIアシスタントの採用とコード生成。 - ビルドとテストのパフォーマンス：CI/CDパイプラインメトリクス、テストカバレッジ、ビルド時間、失敗率（従来の開発とAI支援開発の両方）。 - オペレーション：デプロイ頻度、インフラコスト、監視およびログ情報。 - プロセス：チケット解決時間、インシデント対応データ、機能提供サイクル。 - フィードバック：既存の開発者調査、振り返りノート、オンボーディングフィードバック。 各開発フェーズごとに、すでに収集されているメトリクスを体系的にカタログ化してください。 データソース、その品質、アクセス制限、およびガバナンスに関する考慮事項を文書化してください。たとえば、インシデントレスポンスのチケットは、チームがステータスを更新するか、自動化されたシステムに接続されている場合にのみ有用です。また、バージョン管理におけるコーディング活動に関するデータが存在するかもしれませんが、会社によってはデフォルトでのアクセスが許可されていない場合もあります。このインベントリアプローチは、予想以上に有用なデータが存在することを明らかにし、新しい計測手法よりも分析を優先することを可能にします。ステップ3のワークブックには、このデータインベントリのための例となるワークシートが含まれています。 既存のデータから早期の洞察を得る。既存のデータソースを見つけて文書化したら、貴重な洞察を引き出すためのいくつかの方法を以下に示します。 - 開発履歴の分析： - コミットパターンの分析：頻度の傾向、時間帯のパターン、高い変動のある領域を探します。 - プルリクエストのメトリクスを確認：マージまでの時間、レビューサイクル、コメントパターンを見直します。 - 機能ライフサイクルの追跡：放棄されたプロジェクト、元に戻された変更、その文脈を特定します。 - AIと非AIの開発パターンの比較：AIツールを使用している開発者と従来のアプローチを使用している開発者のメトリクスを見直します。学習曲線、生産性の変化、新たな摩擦点を探ります。 - インシデントと失敗の分析： - コード変更とインシデントの関連付け：特定のコミットやデプロイパターンをシステムの障害にマッピングします。AI支援コーディングやAI対応ツールチェーンとの相関関係を探ります。 - インシデントレポートの研究：再発する問題、応答時間、根本原因を特定します。 - 事後分析文書のレビュー：学んだ教訓や改善提案を抽出し、再発するパターンに注意を払います。 - プロジェクト文書のマイニング： - アーカイブされたプロジェクト仕様の分析：プロジェクトのキャンセルや方針転換の理由を理解します。 - 技術的負債のメモをレビュー：ショートカットが取られた領域とその理由を特定します。 - アーキテクチャ決定文書の検討：過去の決定とその結果から学びます。 - ツールとプラットフォームの使用： - CI/CDパイプラインのパフォーマンスを監視：ビルド時間、失敗率、従来のワークフローとAI支援ワークフローのボトルネックを追跡します。 - プラットフォームサポートチケットのパターンをレビュー：再発する開発者の痛点を特定します。 - ツールの採用データを分析：開発者が実際に使用しているツールと利用可能なツールを理解します。 この構造化されたアプローチは、摩擦点を迅速に特定し、新たなデータ収集の取り組みを開始する前に、既に持っているデータを使用して深い調査が必要な領域を優先するのに役立ちます。 第21章 調査を利用して迅速な洞察を得る チームは、特にDevEx改善イニシアチブを開始する際には、完璧に計測されたシステムを持っていることは稀です。この計測が不足しているため、人々はシステムデータを得るために何年も待たなければならないというジレンマに直面していると感じます。最初のメトリクスを計測するには約6人月、以降の各メトリクスには約3人月がかかるというのが良い見積もりです。しかし、定義に合意し、何を測定するかを決定するのに最も時間がかかることが一般的です。 アクションにつながる洞察を、今すぐアンケートを通じて得ることができます。多くのチームが直面する「どちらか一方」という罠にはまらないでください。アンケートとシステムメトリクスは一緒に使うことで最も効果を発揮し、包括的な開発者体験（DevEx）の洞察を得るためには両方が必要です。アンケートから始めることで、より包括的な測定に向けて構築しながら、開発者の摩擦にすぐに対処を始めることができます。（質的データと量的データを組み合わせる方法や、矛盾する信号の扱いについては、第24章と第25章で詳しく説明します。） アンケートは、数ヶ月ではなく数日で組織全体の摩擦ポイントに関する洞察を提供するため、迅速に始めることができる利点があります。アンケートは、簡単に測定できるものだけでなく、開発者体験全体を捉え、実装コストがほとんどかからないため、GoogleフォームやMicrosoftフォームのような簡単なツールを使ってアンケートを作成し、共有することができます。統合作業や計測機器の設置も不要です。また、アンケートは適応が容易で、時間の経過とともに増えていくシステムデータを補完します。システムデータを目的地の大きな要素と考え、アンケートをすぐに動き出すための手段と捉えてください。 効果的なアンケートを作成するには、偏った質問を避け、十分な回答率を確保し、結果を適切に分析するための慎重な設計が必要です。この章と付随するワークブックでは、アンケートの設計と分析に関するステップバイステップのガイダンスを提供します。より複雑なシナリオでは、この手法に特化した訓練を受けた研究者やコンサルティング会社と提携することを検討してください。 強力なDevExアンケートは長くある必要はなく、むしろ短い方が良いです。組織全体の開発者、または同様のツールチェーンやビジネスインパクトを持つ製品やビジネスユニットにターゲットを絞っていることを確認してください。アクションにつながる洞察を得るために、いくつかの重要な質問に集中しましょう。例えば： 1. 「現在のツールチェーンにどれくらい満足していますか？」（5段階の満足度スケールで測定） 2. 「生産性を妨げるトップ3の障害を選んでください。」（マッピングしたワークフローからリストを提供し、見落としたツールを記入できるようにします） 3. 「選択した各項目があなたの作業をどのくらい妨げますか？」（選択した項目を繰り返し、オプションとして「毎時」「毎日」「毎週」「毎月」「月に1回未満」を提供） 4. 「DevExチームに知っておいてほしい追加の考えや情報を共有してください。」（オープンテキストボックス）このリマインダーを含めることもできます：「機密情報や特定の情報は共有しないでください。」 AIの使用、文化、心理的安全性、または燃え尽き症候群に関する質問を含めることも考慮してください。ステップ3のワークブックには、短いアンケートの例と追加の質問も含まれています。 アンケート結果が届いたら、まず摩擦を定量化します。頻度と普及率に基づいて重み付けされた影響スコアを作成します。その後、アンケートの洞察と利用可能なシステムデータを比較して三角測量を行います。高い影響力と頻度の問題に優先順位を付けて取り組みましょう。あなたの基準となるメトリクスを設定してください。 イニシアティブを立ち上げ、開発者と透明性を持って成果を共有することが重要です。特にアンケートを使用することは強力で、開発者がシステムをどのように見ているかを迅速に把握できます。上記の質問を使うことで、以下のことがわかります。 - 開発者の満足度：研究によれば、これは自己申告による生産性や定着率と高い相関関係があります。 - 生産性の障壁：開発者に自分の作業を妨げる要因をいくつか選ばせることで、摩擦の主な原因を優先順位付けしたリストを得ることができ、改善すべき主要な領域をより明確に定量化できます。 - 摩擦の頻度：選択した各項目がどのくらいの頻度で作業を妨げるかを尋ねることで、考慮すべき領域の重み付けスコアやリストを作成でき、どこに注力すべきかの明確な方向性を得られます。 スタートアップでの迅速なDevExインサイトの取得。エンジニアリングリーダーのトム・ヒップウェルは、会社に入社した際にチームの開発者体験を迅速に理解する必要がありました。彼が参加したのは、シリーズBのスタートアップであるHofy（後にDeelに買収）で、エンジニアは20人以上、リソースは限られていました。彼は、実用的な2ステップのアプローチを開発し、迅速に実行可能なインサイトを得ました。 ステップ1：スキップレベルの会話。トムは、すべてのPM、テックリード、プロダクトデザイナーとオープンエンドのインタビューを行い、主要なテーマや潜在的な問題を特定しました。この定性的な基盤は、彼が適切な質問をするための文脈を提供しました。 ステップ2：迅速なアンケートの実施。完璧なアンケートを作成するのに数週間を費やすのではなく、トムはSPACEフレームワークに基づいて質問票を迅速に作成しました。彼は会話から浮かび上がったテーマに基づいて質問を構成し、分析を容易にするためにメタデータを付加しました。 成果：入社から数週間以内に、トムは定性的なインサイトと定量的なデータを得て、優先事項を導くことができました。彼はチームのオフサイトでアンケート結果を使用し、組織全体の開発者を調整し、共同で焦点を当てるべき領域を特定しました。トムのアプローチは、小規模な組織がアンケートを使用して迅速に広範なDevExインサイトを収集し、最も重要な領域に調査を集中させる方法を示しています。重要なのは、文脈を理解するために会話から始め、その後アンケートを使用して初期の発見を検証し、チーム全体で定量化することでした。 シーン・エリス・テストで価値を測る。アクティブユーザーの指標や満足度スコアは貴重な信号を提供しますが、時にはあなたのソリューションや既存のツールがユーザーにとってどれほど重要になっているかをより直接的に評価する必要があります。シーン・エリス・テストは、スタートアップ企業がプロダクトマーケットフィットを判断するために使用するシンプルで強力な方法であり、内部の開発者ツールにも同様に効果的です。このテストは、次の1つの強力な質問に焦点を当てています。 「もし[あなたのプラットフォーム/ツール]を使えなくなったら、あなたはどう感じますか？」 回答は次の3つの選択肢からなります： - 非常に失望する - 多少失望する - 失望しない（それほど役に立たない） スタートアップとの広範な関わりを通じて、エリスは市場に適合した製品は、ユーザーの少なくとも40％がそのツールを使えなくなった場合に「非常に失望する」と答えることが一貫していることを発見しました。この閾値は、製品の成功を測る信頼できる基準となっています。DevExチームにとって、このテストを四半期ごとに実施することは、従来の指標を超えた貴重な洞察を提供することができます。40％未満のスコアは、あなたのソリューションがまだ不可欠ではないことを示唆しており、改善や洗練の機会があることを意味します。ただし、ユーザーに代替手段がない必須ツールの結果を解釈する際には注意が必要です。このような場合、質問の内容を調整することを検討してください。例えば、「もし開発者ツールを選べるとしたら、[現在のツール]を使えなくなった場合、あなたはどう感じますか？」というように。このような表現は、真のツールの価値と組織の依存度を区別するのに役立ちます。 エリステストを満足度に関する質問と組み合わせることで、高い失望スコアがツールへの愛情を反映しているのか、仕事の必要性を示しているのかをよりよく理解することができます。オープンテキストは有用ですが、重要な制限もあります。オープンテキストの回答は、開発者が選択した理由に関する貴重な文脈を提供することがあります。例えば、「デプロイするために何千行ものコードを書く必要がある」といった開発者のコメントは、デプロイがなぜそんなに難しいのかについての追加情報を提供します。また、オープンテキストは、リストに含めるのを忘れていたものや、リストにあったが開発者が誤解した項目を特定する手段にもなります（例えば、あなたが選択リストにコアツールチェーンのコンポーネントだけを含めたが、リクエストプロセスが最大の遅延を引き起こしている場合など）。オープンテキストは、追加情報を引き出す方法にもなり得ます。何が起こったのか、なぜそうなったのかを教えてくれますが、どれくらいの影響があったのかは示しません。ラベルを付けてテーマを探ることで、インタビューと同様のアプローチが可能です。 数百または数千の回答が得られる可能性があるため、AIやセマンティック分析などのツールを使用してラベルやテーマを要約することが有用です。しかし、オープンテキストには限界があります。定量的な優先順位付けの決定を行うために、自由形式のテキストのみを使用することは強く避けるべきです。すべての人が回答を書く時間を取るわけではなく、調査でテキストを記入する傾向のある人々は、非常に満足しているか非常に不満を抱いているかのどちらかです。これは、中間の情報を見逃すことを意味します。また、回答を定量化することはほぼ不可能です。誰かが4段落を書いた場合、それは短い箇条書きのリストを提供した人よりも生産性に対する障壁が多いことを示すのでしょうか？誰かが回答の中で罵りの言葉を使った場合、それはより大きな問題を示しているのでしょうか？たとえ各回答の問題を数えたとしても、誰かが不満を抱いていて発散する時間があったために10項目を含めた可能性もあり、実際に3項目を慎重にリストアップした人よりも多くの障壁を抱えているとは限りません。 私たちの経験では、主に自由記述形式のフィールドに基づく優先順位付けは、成功した改善とほとんど相関しないことが多いです。これは、これらの固有の制限が原因です。第22章では、システムメトリクスへの投資について説明します。 DevEx（開発者エクスペリエンス）の旅が進むにつれて、データソースは自然に進化していきます。初めて取り組む際には、調査に大きく依存（約80％）し、システムデータ（約20％）を少し取り入れることで、開発者の痛点に関する迅速で広範な洞察を得ることができます。取り組みが進むにつれて、より多くのシステムを計測するようになると、このバランスはS字曲線のパターンに沿って変化します。システムデータは徐々に増加し、さらに自動収集機能を構築することで大幅に増加します。成熟したDevExプログラムでは、システムデータが自動的に収集できる量のため、情報の大部分を占めることがよくあります。調査は旅の途中で重要な役割を果たし、完全に消えることはありません。成熟したプログラムでも、計測の決定、隠れた摩擦点の発見、開発者の満足度の測定のために調査データを引き続き使用します。重要なのは、システムデータが精度と継続的なモニタリングを提供する一方で、調査データはシステムでは捉えられない文脈や人間の視点を提供することです。 調査疲れには注意が必要です。これは誰もが知っていることですが、繰り返す価値があります。開発者に調査を次々と送り続けると、彼らは実際に必要な洞察を提供しなくなります。どのデータを取得できるか、できないか、どれくらいの頻度で取得できるかについて現実的である必要があります。開発者は限られた注意を持っており、仕事が最優先です。彼らは一日中複雑な問題を解決しています。調査に答えるためにその作業を中断させると、限られた注意の銀行から引き出しを行うことになります。引き出しが多すぎると、口座は閉じてしまいます。 調査成功のためのいくつかのヒントを紹介します： - 15分以内に収めること。調査が15分以上かかる場合、すでに失敗です。開発者は途中で放棄するか、終わらせるために急いで回答するでしょう。 - タイミングの重要性。月次調査は忘れましょう。3か月または6か月ごとのサイクルで劇的に良い結果が得られています。なぜなら、前回のフィードバックに基づいて意味のある変更を実施するのに大体それくらいの時間がかかり、開発者の作業に最小限の中断をもたらすからです。さらなる入力を求める前に進捗を示しましょう。 - 統合の重要性。すでに開発者向けの調査がある場合、それが必要な情報を提供していないなら、競合する調査を立ち上げないでください。それは確立されたプレーヤーに対抗することになり（悪手）、開発者に追加の作業をもたらすことになります（これも悪手です）。代わりに、既存の調査チームと提携し、あなたの質問を補完的なものとして位置づけましょう。 - 差別化の要件。複数の調査は共存できますが、開発者の心の中で明確で異なる位置づけがあるときに最も成功します。 文化調査と技術ワークフロー調査は、適切に位置づけられ、数週間または数ヶ月の間隔を置いて実施されれば、どちらも成功する可能性があります。最終確認を行いましょう。調査を「送信」する前に、自問してみてください。「もし私が開発者の立場だったら、今やっていることを中断してこの質問に答えるだろうか？」また、「この調査の結果に興味を持つだろうか？誰かと結果を共有したいと思うだろうか？」もし答えが明確な「はい」でないなら、アプローチを見直す必要があります。開発者からのフィードバックをうまく得ているチームは、調査の数が多いチームではなく、開発者が置かれている文脈を尊重し、それに応じてフィードバックのリクエストを行うチームです。調査データは、良好なシステムデータがない場合に非常に役立ちますが、完璧なシステムデータを待ってから行動を起こすという罠にはまらないようにしましょう。完璧は進歩の敵です。システムデータの移行は、組織全体で合理的な品質とカバレッジを持つデータソースを特定することで自然に進行します。たとえば、プルリクエストが摩擦のポイントである場合、PRサイクルタイム（PRを完了するのにかかる時間）やPR滞留時間（全体のサイクルタイムの一部で、PRがアクションを待つ時間）などの指標を分析することが重要です。これらの客観的な指標は、特定の摩擦ポイントに関する正確なデータを提供します。 データを考慮する際には、DevExの取り組みを誤解させる可能性のある一般的な誤謬に注意してください。街灯効果は、すでに強力なシステムデータがある領域にのみ焦点を当てるときに発生します。測定が容易なものに注意を限定しないでください。成熟したDevEx改善プログラムであっても、調査は新たな問題、主観的な体験、計測が難しい領域について重要な洞察を提供し続けます。これが、システムデータが全体の指標ポートフォリオを支配するようになっても、調査の要素を維持することが価値がある理由です。同様に重要なのは、スナップショットの誤謬を避けることです。単一の調査やデータ収集を永続的な真実として扱わないでください。DevExのニーズは、組織の変化、技術の進歩、開発者の経験の蓄積に伴って進化します。定期的なパルス調査と継続的なシステムデータ分析を計画し、開発者体験の正確で最新の状況を維持しましょう。 第23章　正しいデータをキャッチすることを確実にする あなたのデータは、単に数えやすいものだけでなく、DevExのいくつかの次元をカバーするべきです。ソフトウェア開発において実際に重要な指標を探る前に、私たちが本当に測ろうとしているものを理解するために一歩引いて考える価値があります。Googleのタイタス・ウィンターズと彼の同僚たちが指摘するように、この分野の最大の未解決問題の一つは、開発者の生産性を直接測定できないことです。すべてのソフトウェアの変更はユニークであり、創造的で思慮深い人間の作業を単純なカウント（コードの行数、提供された機能、ストーリーポイントなど）に還元しようとする試みは、ソフトウェア開発の本質を見失っています。 この測定の課題は、ソフトウェア開発が実際には異なる目標と制約を持つ3つのプロセス（開発、デプロイメント、運用）を含んでいることを認識することで明確になります。開発は創造的で人間中心の作業、デプロイメントは自動化された機械駆動のプロセス、運用は予期しない生産シナリオに最適化することを指します。この3つに同じ指標を適用しようとすると、混乱やインセンティブの不一致が生じます。よく見られる誤りは、チームがシステムデータのみを使用することです。表面的には、システムデータは計測しやすく、収集も簡単に思えるからです。エンジニアはシステムデータに慣れている一方で、調査データにはあまり精通していません。しかし、私たちはこのデータが全体像を捉えることができないことを議論してきました。さらに、システムデータはしばしばカウントの形で提供されるため、開発者の体験における非常に重要な側面を見逃してしまいます。 最も効果的なデータ戦略は、問題から指標へと逆算することです。まず、調査で明らかになった痛点から始め、次にそれらの領域での改善を理解し追跡するために必要な具体的なデータを特定します。たとえば、調査に参加した複数の開発者が「テストを書くのが難しい」と言っている場合、フォローアップの会話を通じて、開発者がテスト用の合成データを生成するための良いシステムを欠いていることがわかります。その結果、過剰な統合テストや過剰にモックされたユニットテストが生じています。これで、測定すべきことがわかります：ユニットテストのカバレッジと統合テストのカバレッジ（ユニットカバレッジの増加を望む）およびコード内のモック作成のパターン（これを減少させたい）です。このアプローチは、指標が開発者の摩擦に直接結びつくことを保証し、単に計測が便利なものを測るだけではありません。 また、指標が表す開発者体験の次元についても考慮することをお勧めします。SPACE（満足度、パフォーマンス、活動、コミュニケーション、効率と流れ）などのフレームワークは、測定が容易なものだけでなく、全体像を捉えるのに役立ちます。たとえば、すでに計測されている指標に焦点を当てたデータ収集戦略は、チームにバージョン管理からのデータ（コード行数、コミット数、プルリクエスト数など）や、チケットシステムからのデータ（顧客に影響を与えるインシデントの数など）を使用するよう促すことがよくあります。しかし、これでは実際に何が起こっているのかを歪めた見方を提供する可能性があります。チームは締切やリリース日を守るためにプッシュすることができ、その結果、コミット数やプルリクエスト数が増加することがあります。しかし同時に、開発者は環境を設定しデプロイするための手作業や、変更を承認するプロセスの難しさに苦しんでいるかもしれません。 満足度や主要な障壁を捉えるための調査質問、またはテストスイートの結果などの品質指標を追加することで、何が起こっているのか、調査すべき場所についてより包括的な視点を得ることができます。このバランスは、複雑でAIを活用したワークフローを評価する際に特に重要です。また、強力なビジネスケースを構築するためのデータ収集を忘れないでください。 多くのDevEx改善の取り組みは、ビルド時間やテストの効果といった技術的な指標に狭く焦点を当てすぎるため、つまずいてしまいます。これらの測定は重要ですが、すべての利害関係者に響くわけではなく、ビジネスの価値を明確に示すことも難しいのです。第1部では、ビジネスケースを作成する重要性について議論し、ステップ1では主要な利害関係者とその優先事項を特定しました。今、あなたの利害関係者リストを再確認し、技術的な改善を収益の推進要因やコスト削減に翻訳することで、リーダーシップに響く指標を含めてください。 - ビルド時間を測定するだけでなく、ビルド中に消費されるコンピュートリソースを追跡し、インフラコストの削減を見積もりましょう。ワークフローで削減されたステップ数を数えるのではなく、開発者が節約した時間を定量化して生産性の向上を示しましょう。デプロイ頻度の改善を市場の反応性や顧客満足度の指標に結びつけてください。生産インシデントのコストを集計し、より良い開発者ツールによってインシデントを減少させることの財務的影響を計算できるようにします。これらのビジネス指向の指標を取り組みの初期段階で収集し、基準を確立することが重要です。この初期の測定がなければ、改善を定量化し、あなたの仕事の真の影響を示すのが難しくなります。これらの基準比較は、DevExの改善を経営陣や非技術的な利害関係者が理解し、評価する組織の成功指標に結びつける、説得力のあるビフォーアフターのストーリーを生み出します。（この点についてはステップ7でさらに詳しく議論します。） データが増えるにつれて、それを分析し結論を導き出す際にはより慎重になる必要があります。インタビューやデータポイントが少ない場合は、データを要約し、手動でパターンを探すことができますが、データが増えると、収集方法に対してより慎重になり、分析方法に対してもより規律を持つことが重要になります。詳細な分析や大規模なデータセットについてはデータサイエンスチームと提携することをお勧めしますが、ここではいくつかのベストプラクティスと経験則を共有します。 何が起こっているのかを理解するために、代表的なデータを収集しましょう。正確な状況を把握するためには、組織全体からデータを集める必要があります。インタビュー、調査、システムログなどのデータ収集戦略は、あなたの結論に直接影響します。参加者に関する記述情報（経験レベルやチームなど）を収集することで、コホート分析が可能になり、異なるグループ間でパターンを比較できます。たとえば、シニア開発者がジュニア開発者とは異なる課題に直面していることや、モバイルチームがSaaSチームとは異なるワークフローボトルネックを抱えていることがわかるかもしれません。レガシーアプリケーションに取り組む開発者からのみフィードバックを集めると、モバイルやSaaSチームが直面する特有の課題を見逃してしまいます。データを収集する前に、サンプリングマトリックスを作成して、取り組みをガイドしましょう。 （データサイエンスチームはこれを「サンプリング」と呼び、洗練された統計手法を用いますが、シンプルなフレームワークから始めることもできます。）まずは、以下のような重要な組織の次元をマッピングしてみましょう： - プロダクトエリア（レガシー、モバイル、SaaS） - 開発者の役割（ジュニア、シニア、アーキテクト） - プラットフォームの種類 - チームの所在地やタイムゾーン 開発者のワークフローやSPACE測定次元に対して、これらの組織の次元をマッピングすることを考えてみてください。サンプリングマトリックスをビンゴカードのように考え、すべてのスペースを埋める必要はありませんが、重要なエリアにバランスよくカバーしつつ、時間をかけてカバー範囲と質を向上させることを目指しましょう。データマッピングマトリックスの詳細な例は、ステップ3のワークブックの「データマッピング」セクションに含まれています。 何が起こっているのかを理解するために十分なデータを集めましょう。あなたの目標は、洞察や次のステップに自信を持てるだけのデータを集めることであり、学術的な統計的有意性にこだわりすぎないことです。以下は、始めたばかりの方にとっての良い指針です。 - アンケートの場合、30〜50件の回答を目指しましょう。多い方が良いですが、このレベルで良い洞察が得られ始めます。100件以上の回答を得ると、実用的な目的のためにかなり安定した結果が得られることが多いです。組織の構造や技術プラットフォームの使用状況、全社的な文化の違いなどに応じて、各ビジネスユニットやプロダクトチームごとに30〜50件の回答を集めることをお勧めします。 - インタビューの場合、5〜8人から始めましょう。新しい情報があまり聞こえなくなるまで続けてください。通常、特定のトピックについては12〜15件のインタビューで十分です。（これを「飽和に達する」と呼ぶことがあります。）もしすべてのインタビューで全く新しい情報が得られる場合は、まだ学び続けている状態であり、さらに多くのインタビューが必要です。 - システムデータの場合、包括的なカバーを目指しましょう。理想的には、ターゲットシステムや対象集団の少なくとも80％からデータを収集することです。データの定義が一貫しており、十分に文書化されていることを確認してください（例：「ビルド失敗」や「デプロイメント」とは何か）。タイムスタンプの欠落、不完全なログ、一貫性のないフォーマットなど、データの質に関する問題に注意してください。時間をかけて測定する場合は、使用パターンの典型的な変動を考慮して、少なくとも数週間のデータを収集しましょう。季節性にも特に注意が必要です。休日や大規模なリリースサイクル中にデータを収集すると、典型的なパターンを反映しない可能性があります。 重要なのは、すべてのデータタイプにおいてバランスの取れた代表性を持つことです。主観的なデータについては、最も関与しているユーザーや不満を持っているユーザーだけでなく、さまざまなタイプのユーザーや参加者から意見を聞いていることを確認してください。システムデータについては、異なる環境、構成、使用パターンをキャプチャしていることを確認しましょう。特定のユーザータイプからの回答が主に得られている場合や、特定のシステムからデータが欠落している場合など、気づいたギャップやバイアスを文書化してください。このコンテキストが、あなたの発見をよりよく理解するのに役立ちます。 「十分に良い」データはスタートするには十分ですが、組織全体のカバレッジと質を継続的に改善することが重要です（より良い調査設計や精度向上のための追加の計測手段を通じて）。最も重要なのは、効果的なデータ収集は単に魔法の数字を達成することではなく、組織全体で何が起こっているのかを理解し、情報に基づいた意思決定を行うためのバランスの取れたインプットを集めることです。学術的でない作業においては、誰を測定し、何を測定しているのか、データの盲点について考慮しつつ、実用的であることが求められます。AIは必要なデータにどのように影響を与えるのでしょうか？AIの導入は、新たなデータ収集の機会を提供すると同時に、既存の指標の解釈方法に変化をもたらす可能性があります。かつては迅速または効率的と考えられていたことも、AIを活用したワークフローでは再調整が必要になるかもしれません。 開発ワークフローにAIツールを導入する際には、以下の点を考慮してください： - 比較指標の追跡（AI支援の有無によるPRのターンアラウンドタイム）。 - 質的影響の測定（AIレビューされたPRの受け入れ/マージ率）。 - 採用パターンのモニタリング（どのチームや開発者がAIツールを最も効果的に活用しているか）。 - 複雑さの違いの評価（AIツールは単純なタスクと複雑なタスクで異なる使われ方をしているか）。 何が起こっているのかを理解するために、十分な人数から十分なデータを収集してください。調査の場合、30％以上の回答率はほとんどの組織の文脈でかなり良いとされています。しかし、20～30％は一般的で、通常は実用的なデータを提供します。15％を下回る場合は、配布方法に問題があるのか、調査自体が長すぎるか複雑すぎるのかを考え始めるべきです。ただし、回答率の数字には文脈が必要です。広範囲なコールドメール調査で20％の回答率は特に大きな組織では問題ないかもしれませんが、非常に関与度の高いユーザーを対象とした調査では懸念材料となります。同様に、25％の回答率があなたの母集団のバランスの取れたミックスを表している場合は素晴らしいですが、パワーユーザーのみを捉えているか、すべてのレガシー開発者を見逃している場合は問題です。 インタビューのリクエストについては、組織内での接触であれば40～50％の人が受け入れることを期待してください。インタビューのためのコールドアウトリーチは通常、受け入れ率が低く、15～25％になることが多いです。それよりもはるかに低い受け入れ率を得ている場合は、予定しているインタビューの時間を短縮したり、スケジュールに柔軟性を持たせたり、価値提案を明確にしたり、インセンティブを提供したり、招待状がスパムフィルターに引っかかっていないか確認したりすることを検討してください。組織やチームの文化によっては、DMに対してより良い反応を示す開発者もいます。 高い回答率を築くためには、信頼を構築し、影響を示すことで、驚くほど高い参加率を時間をかけて達成することができます。例えば、アマゾンの... 年次開発者調査は、完了に1時間かかるにもかかわらず、90％以上の回答率を達成しました。これは、開発者に対して彼らのフィードバックが実際の変化を促したことを一貫して示し、結果を透明に報告することで得られた素晴らしい成果です。同様に、DXプラットフォームを利用している数百の企業も、思慮深い調査設計、透明なダッシュボード、データに基づいたフォローアップアクションのおかげで、90％以上の回答率を見ています。重要な洞察は、回答率は調査そのものだけでなく、フィードバックと行動の文化全体に関わっているということです。開発者が自分の意見が実際の変化をもたらしているのを見たとき、彼らは将来の調査にもっと時間をかける意欲を持ちます。開発者のフィードバックを分析する際は、生の数値よりも代表性に焦点を当てるべきです。異なるチーム、役割、経験レベルからの開発者の30％の回答率は、1つのグループからの70％の回答率よりも、組織全体のパターンについて多くを教えてくれます。この原則は、調査データと行動指標の両方に当てはまります。たとえば、80％の回答者がAPIに苦労している場合、それが異なるチームにまたがる開発者であれば重要ですが、すべてが1つの専門チームからであれば、普遍的な問題ではなくチーム特有の問題を見ている可能性があります。インフラエンジニアとモバイル開発者は、しばしば全く異なる摩擦点を持つため、広範な結論を出す前に、データが誰を代表しているのかを常に考慮してください。 第24章 データを実行可能な洞察に変える データを持っていることと、それをどう活用するかの間には、多くのDevEx（開発者体験）イニシアチブが停滞するギャップがあります。あなたは指標を収集しましたが、次は何をすべきでしょうか？目標は統計の専門家になることではなく、開発者体験を改善するための情報に基づいた意思決定を行うことです。基本的な統計であっても、摩擦のパターンについて良いアイデアを提供してくれます。開発者がどこでつまずいているのか、どのツールを好んで使用しているのかを見つけるために、複雑な分析は必要ありません。DevExデータを掘り下げるときは、基本から始めましょう。平均値、中央値、頻度カウントは多くのことを明らかにします。たとえば、ビルド時間の中央値が8分で平均が15分であれば、これは一部のビルドが他よりもはるかに長くかかっていることを示しており、調査する価値があります。これは、注意が必要なパフォーマンスのボトルネックを示す可能性があります。 これらの基本的な統計から得られる実行可能な洞察にはいくつかのタイプがあります： パフォーマンスのボトルネックは、統計的な指標が一致しないときに現れます。ビルド時間の中央値と平均のギャップは、インフラの不整合や開発プロセスを遅らせる問題のあるエッジケースを示しています。たとえば： テストスイートの時間が中央値5分、平均12分の場合 → 不安定なテストやリソースの競合を調査する。コードレビューの承認時間が平均2日、中央値4時間の場合 → 承認プロセスのボトルネックやレビュアーの可用性の問題を探る。 ローカル開発環境のセットアップには平均で30分かかりますが、20％の開発者は2時間かかっています。この問題を解決するためには、セットアップのドキュメントやツールの互換性を確認する必要があります。使用パターンは、頻度のカウントや時間の経過に伴うトレンドとして現れます。デプロイ頻度のトレンドラインを分析することで、チームが月曜日にデプロイをあまり行わないことが明らかになるかもしれません。これにより、チームのワークフローや会議のスケジュール、さらには週末のインシデント回復パターンについての疑問が生じることがあります。例えば： - 社内ツールの使用が、全社的なアップデート後に急激に減少している場合 > 新しいバージョンに使い勝手の問題や機能の欠如があるかもしれません。 - 「ビルド失敗」のSlackでの言及が午後3時に集中している場合 > ピーク時にCI/CDリソースが不足している可能性を示唆しています。 摩擦点は、分布や頻度のカウントを通じて明らかになります。開発者が最も多くの時間を費やしている場所や最も多くのエラーに遭遇している場所を分析することで、ボトルネックを特定できます。例えば： + 調査データによると、70％の開発者が「コードレビューを待っていること」を最も大きなフラストレーションとして挙げています > レビューワーの作業負荷分布や承認ワークフローを調査しましょう。 + APIドキュメントが全社内サポートリクエストの45％を占めている場合 > より良いドキュメント、例、またはセルフサービスツールに投資しましょう。 - 60％の開発者が環境セットアップの問題に毎日30分以上を費やしていると報告している場合 > コンテナ化や自動環境プロビジョニングに注力しましょう。 視覚化は非常に有効です。抽象的な数字を人々がすぐに理解できるパターンに変換します。ビルド時間のヒストグラムは、問題のあるビルドが「ロングテール」を持っていることを即座に示すかもしれませんし、デプロイ頻度のトレンドラインは、チームが月曜日や会計年度末にデプロイをあまり行わないことを明らかにするかもしれません。これらの視覚的パターンは、しばしば「ここでこの減少が見られるのはなぜか？」や「この指標が改善されたときに何が変わったのか？」といった適切な質問を引き起こします。さらに、視覚化は、数値に埋もれてしまう可能性のある利害関係者とインサイトを共有するのを容易にします。 LinkedInが複雑なデータをシンプルにした方法。LinkedInのDeveloper Insights Hubは、古典的な課題に直面していました。忙しいエンジニアリングリーダーを圧倒することなく、包括的な開発者の生産性指標をどのように示すかということです。彼らの解決策は、プログレッシブディスクロージャーでした。シンプルな情報から始め、必要に応じて複雑さを追加するというアプローチです。メインダッシュボードには、現在の指標値と最近の変化のみが表示されます。マネージャーが調査したい場合、1クリックで過去のトレンドや次元別の内訳が表示されます。この層状のアプローチは、実行可能なインサイトを得るために重要でした。「ビルド時間が20％増加した」とただ見つめるのではなく、マネージャーは詳細を掘り下げて特定の問題を発見できました。例えば、問題は特定のリポジトリで作業しているシンガポールのモバイル開発者に特有でした。LinkedInの成功は、適切なタイミングで適切なレベルの詳細を提示し、圧倒的な指標を問題の特定からターゲットを絞ったアクションへの明確な道に変えることにありました。 多くの分析は自分で行うことができますが、時にはデータサイエンティストと協力するのが最良の選択です。データサイエンティストを招くことを検討すべき状況は以下の通りです： - 複雑なユーザージャーニーを扱っていて、適切なファネル分析が必要な場合。 - 現在のパターンに基づいて将来の摩擦ポイントを予測したい場合。 - ログやアンケートの回答などの非構造化データを大規模に分析する必要がある場合（ただし、AIツールはこの分野でますます優れた能力を発揮しています）。 - 異なる指標（例えば、ビルド時間とデプロイ頻度）間の相関関係を確立しようとしている場合。 - 時間の経過や季節ごとの違いを調査したい場合。 結果やビジュアライゼーションを共有する際には、プライバシーとセキュリティを考慮することが重要です。個々の開発者を保護しつつ、意味のある洞察を得ることが鍵となります。良いルールとして「5の法則」があります：5人未満の開発者のグループに関するデータは決して表示しないことです。これにより、特定の開発者が特定のAPIやデプロイシステムで苦労していることを特定されるのを防ぎます。また、アンケートの自由記述コメントには特に注意が必要です。これらには、意図せずに機密情報が含まれている可能性があります。 ステップ4 戦略と優先順位を決定する すべてのDevExの問題を一度に解決することはできませんので、優先順位を決定し、コミュニケーションを図るための体系的な方法が必要です。収集したデータは、開発者体験を改善するための多くの機会を明らかにしました。しかし、限られた時間とリソースでは、すべてに一度に対処することはできません。この章では、共通の基準を用いてDevExの課題を評価し、意思決定を明確にし、ステークホルダーの合意を得る方法を示します。あなたの増え続けるリストの各項目は誰かにとって重要ですが、他の誰かには響かないかもしれません。実行に移るためにリストを優先順位付けしたくなるかもしれませんが、それには注意が必要です。そのランキングアルゴリズムはあなたの頭の中にのみ存在し、エラーやバイアスが生じやすく、他の人と共有することが難しいためです—フィードバックや合意を得るためにも。 第25章 DevExの取り組みを集中させる RICE基準を使用して意思決定を明確にし、実データをもとに合意を得ましょう。ある程度のレベルで、開発者が直面するすべての課題は、他の課題と関連しているか、密接に統合されています。たとえば、誰かがビルド時間が遅すぎると言った場合、それはビルドを並列化やキャッシングなどのビルド加速技術を活用するために書き直す必要があるからなのか、それとも基盤となるアーキテクチャを再設計する必要があるからなのか？テストスイートが遅すぎる場合、それはテストをパフォーマンスを考慮して更新する必要があるからなのか（たとえば、テストスイートが必要なテストのみを実行する必要があるから）、それとも多くの不安定なテストが原因でテストハーネスが失敗したテストを何度も再実行し、テスト実行時間が長くなっているからなのか（そして、計算コストが大幅に増加しているから）？システムは相互に関連していますが、最初に課題を独立して考え、その後それらの課題がシステムにどのように関連しているかを考えることが役立ちます。これにより、課題を評価し、作業の優先順位を付けることができます。データを収集し、リスニングツアーを行ったので、開発者が現在直面している主要な課題について良い感触を持っているはずです—初めてこのプロセスを行う場合でも、いくつかの課題に対処した後に再訪問する場合でも。しかし、これらの課題を特定するだけでは不十分です。どの課題を優先して行動し、リソースを割り当てるべきかを明確にする必要があります。ステップ2で迅速な成果を得るために使用したRICEフレームワークは、リスニングツアーやメトリクスから得たデータに基づく体系的な評価ツールとなります。 優先順位を付ける上で重要な部分は「ノー」と言うことです。スティーブ・ジョブズはこの課題をよく理解していました。「人々は、フォーカスすることは、注力すべきことにイエスと言うことだと思っています。しかし、それは全く違います。フォーカスとは、他の100の良いアイデアにノーと言うことです。慎重に選ばなければなりません。私は実際に、やらなかったことに対しても誇りを持っています。イノベーションとは、1,000のことにノーと言うことです。」 この原則は、内部ユーザー向けの製品を構築する際にも同様に強く適用されます。RICEは、あなたがノーと言うのを助けてくれます。 体系的に全体像を評価することを強制することで、最も大きな不満や興味深い技術的課題だけでなく、全体を見渡すことが求められます。決定が下された後は、その決定に使用した基準の一部またはすべてを、組織全体と共有することも選択できます。私たちは、優先順位の背後にある理由を共有することで、異なる優先順位を持つチームを納得させる手助けになることがわかりました。たとえば、彼らの項目が低い優先順位に置かれたことに不満を持っていても、他の項目が先に完了することで最終製品が利益を得ることを理解すると、彼らの考え方が変わることがあります。 CloudTechを紹介します：あなたのRICEフレームワークガイドです。このフレームワークが実際にどのように機能するかを示すために、DevExチームが5つの主要な課題を特定した中規模のSaaS企業であるCloudTechを追っていきます。これらの課題は、手動デプロイ（複数人が必要な半日プロセス）、遅いビルド時間（45分以上）、不安定なテスト（30％の失敗率）、不十分なオンボーディングドキュメント（初回コミットまでに2週間以上）、および一貫性のないローカル環境です。彼らは経営陣の支援を受けているため、大規模な取り組みとローカルな取り組みの両方から選択できます。次の章では、彼らがRICEフレームワークを使用して厳しい優先順位決定を行った方法を見ていきます。 第26章：関連する基準を使用して開発者体験の優先順位を設定する すべてが優先事項である場合、何も優先事項ではありません。ステップ2では、早期の機会を迅速に評価するためのQuick RICEを紹介しました。今、より多くのデータとステークホルダーの意見が得られたので、より包括的なRICE分析を行う時が来ました。 promising candidatesを特定するためのクイックバージョンとは異なり、この体系的なアプローチは、各要素を評価するためにメトリクスを使用します。RICEは、成功の可能性が高いプロジェクトを見極める手助けをし、高いリーチ、高いインパクト、高い信頼性を持ちながら、労力を低く抑えることができます。 RICEの公式： （リーチ x インパクト x 信頼性）+ 労力 = RICEスコア リーチは、どれだけの開発者が影響を受け、どのくらいの頻度で影響を受けるかを測定します。これは、真の影響の規模を理解するための基盤です。考慮すべき質問： - これに影響を受ける開発者は何人ですか？ - 影響の頻度はどのくらいですか？（日常的な摩擦は通常、四半期ごとの痛みを上回ります。） - これは高いレバレッジを持つ開発者に不均衡に影響を与えますか？ すべての計算で一貫した単位を使用してください。たとえば、一部の項目の「日常的な影響」と他の項目の「影響を受ける開発者の数」を混在させないようにします。これにより、異なるタイプの改善間で公平な比較が保証されます。 インパクトは、この変更が開発者の日常体験をどれだけ改善するかを評価します。考慮すべき質問： - 開発者はこの改善をすぐに感じるでしょうか？ - この変更は彼らの日常体験をどれだけ大きく変えるでしょうか？ - これは主要な制約を取り除くのか、それとも小さな摩擦を減少させるだけなのか？ インパクトをスコアリングする際は、シンプルな1-3のスケールを使用します： - 1 = 低インパクト：ワークフローへの軽微な改善。 - 2 = 中程度のインパクト：目に見える生産性の向上。 - 3 = 高インパクト：主要なボトルネックの排除または大幅な時間の節約。 信頼度は、イニシアティブが計画通りに成功する確信の度合いを反映し、通常はパーセンテージ（例：80%の信頼度）で表されます。以下の点を考慮してください： + 技術的な実現可能性と既知の解決策 + チームの専門知識と能力 + 依存関係と潜在的な障害 - 過去の類似イニシアティブの経験 労力は、必要な総投資を示し、通常は人月で表されます。以下を必ず含めてください： - 開発時間 + テストと展開 - ドキュメント作成とトレーニング - 継続的なメンテナンスの考慮 CloudTechの主要な課題に対するRICEスコアリングを見てみましょう。CloudTechの主要な課題は、手動展開、遅いビルド時間、不安定なテスト、貧弱なオンボーディングドキュメント、一貫性のないローカル環境でした。 信頼度、リーチ、インパクト（%の信頼度）、成功の確率は以下の式で計算されます： \[ \text{Confidence} = \frac{R \times I \times C}{E} \] 手動展開： - 160人の開発者 - 高い信頼度、明確な技術的経路 - 1日あたり2回の展開、週5日で計8回の展開 - ボトルネックを排除 - 実績のあるツール - 人月：1,275 遅いビルド時間： - 150人の開発者 - 高い信頼度、アーキテクチャの変更が必要 - 1日あたり5回のビルド、750のデイリーインパクト - 45分以上の待機時間 - 人月：183 不安定なテスト： - 150人の開発者 - 中程度の信頼度、複雑な解決策が必要 - 1日あたり3回のテスト実行、450のデイリーインパクト - 根本原因の調査が必要 - 人月：75 貧弱なオンボーディングドキュメント： - 年間24人の新入社員 - 高い信頼度、時間を短縮 - 1日あたりのドキュメント使用量から推定 - 人月：53 これらのRICEスコアに基づいて、CloudTechは手動展開（1,275）、次にビルド時間（183）、ローカル環境（120）、不安定なテスト（75）、オンボーディングドキュメント（53）の順に優先順位を付けるでしょう。 RICEは堅実な基盤を提供しますが、通常はリソースとステークホルダーの合意が前提とされる製品開発に使用されます。 DevEx（開発者体験）イニシアチブは、追加の質問をすることでより良い結果を得ることができます。これらの制約に対処するための優れた方法は、「5つのなぜ」の修正版を実施することです。ただし、「なぜ？」と尋ねるのではなく、「次に取り組むべき課題は何か？」と問いかけてみてください。そして、その都度、リソース、実行、ビジネスニーズにとって重要なことに焦点を当てます。また、各課題をどのように評価したのか、その理由をメモしておくことをお勧めします。これは、ステークホルダーやチームと話し合う際に役立ちます。ビジネスへの影響や戦略的な整合性を探りましょう。まず、「この課題について、ビジネスリーダーが関心を持つ指標で話すのは簡単か？」と尋ねてみてください。 高い影響を持つ問題は、自然にビジネスへの影響に結びつきます。例えば、50人の開発者が毎日30分を失うと、時間の損失を計算できます。リーダーシップにプレゼンテーションを行う際には、彼らが理解できる指標を通じて明確なビジネス価値を示すイニシアチブが必要です。具体的には、開発者の時間の節約、回避されたコンピューティングコスト、市場投入までの時間の改善などです。同様に、「このイニシアチブは、既存の作業とどのように整合しているか、またはそれを活用してビジネス価値を最大化するか？」という点も重要です。 進行中の取り組みやビジネスの動きとつながるイニシアチブは、勢い、共有リソース、確立された優先事項を通じて、より大きな影響をもたらすことが多いです。例えば、組織が最近ログ記録や可視化インフラに投資した場合、この投資を活用して可視性の課題を解決するDevExの改善は、より迅速な結果を低コストでもたらす可能性があります。同様に、DevExの主要な課題がコンプライアンス関連の摩擦を減らすことであれば、進行中のセキュリティイニシアチブと連携することで、同じ努力から二重のビジネス価値を生み出すことができます。これらをリーダーシップに強調することで、あなたのDevExイニシアチブがより広範な組織戦略に統合されていることを示すことができます。 集団的な行動とローカルな行動について考えてみましょう。もう一つの質問は、「どの課題が組織全体の努力を必要とし、どの課題がチームレベルの修正で済むのか？」です。 広範囲に及ぶ問題は、複数のチームにまたがるため、集団的な行動を必要とすることが多いです。これらは、チーム間での高いコミュニケーションと調整を必要とします。どのプロジェクトが組織の力を必要とし、どのプロジェクトがチーム特有のアプローチで対応できるかを理解することで、あなたのアプローチを制御範囲に合わせることができます。 集団的な行動が求められる候補： - 協調的な投資から恩恵を受けるアーキテクチャやプロセスの変更。 - チームレベルのロードマップ計画で脇に追いやられるシステム全体のアップグレードやセキュリティパッチの適用。 - 元の範囲を超えて中央集権的なサポートが必要なローカルなDevEx作業。 例えば、内部のプロダクトチームが他のチームが採用したいと思う優れたCI/CDパイプラインを構築した場合、需要は急速にキャパシティを超えます。プロダクトチームが全組織をサポートするのは理にかなわないことが多いです。 ローカルな行動が求められる候補： - 自動テストの実践の改善。 - 継続的インテグレーションのワークフロー。 - トランクベースの開発。 重要なのは、どの課題が組織全体の力を必要とし、どの課題が地域のワークフローやニーズに合わせたチーム特有のアプローチからより多くの利益を得るかを区別することです。プロジェクトが地域的または集団的なアクションを必要とするかを理解することで、自分の管理範囲に合ったアプローチを選ぶことができます。この点については、ステップ6でさらに詳しく探ります。 CloudTechの集団対地域の評価： - 手動デプロイメント：集団的—中央のCI/CDプラットフォームへの投資が必要。 - ビルド時間：集団的および地域的—アーキテクチャの変更（集団的）とチームの実践（地域的）の組み合わせ。 - 不安定なテスト：集団的および地域的—すべてのチームに影響し、各チームが一部のテストスイートを改善できるが、解決策を単独で所有するチームはない。 - オンボーディングドキュメント：地域的—各チームが自分たちのドキュメントを改善できる。 - ローカル環境：地域的—チームが自分たちのセットアップを標準化できる。 タイムライン、緊急性、組織の準備状況を考慮してください。ここでの重要な質問は以下の通りです： - 「最初に取り組むべき課題は何か？それは最も早く完了できるものか？」 - 「内部に必要なスキルは揃っているか、それとも外部の専門知識が必要か？」 - 「現在のリソースと能力でこの課題に対処できるか？」 - 「待つことで悪化する課題はどれで、それがどんな問題を引き起こすか？」 - 「この取り組みは私たちの組織の自然なビジネスリズムとどのように整合するか？」 3〜6か月で進展を見せることは、勢いを維持し、価値を示すために重要です。また、既存のリソースを再配分することで実施できる取り組みは、新たな人員を必要とするものよりも承認の障壁が少ないことが多く、特に最初の段階ではその傾向が強いです。タイミングも重要です—リリースのピークシーズンに開発者ツールの大規模な見直しを行うと失敗する可能性が高いですが、同じ取り組みが計画されたエンジニアリング投資期間中には成功するかもしれません。 CloudTechのタイムライン評価： - 手動デプロイメント：中（中速）—基本的な自動化には3〜4か月。 - ビルド時間：低（遅い）—アーキテクチャの変更が必要で、6か月以上。 - 不安定なテスト：低（遅い）—深い調査が必要で、6か月以上。 - オンボーディングドキュメント：高（速い）—4〜6週間で大幅に改善可能（AIツールを使えばさらに早く）。 - ローカル環境：高（速い）—Dockerの標準化は6〜8週間で実施可能。 制約とリスクを考慮してください。ここでの重要な質問は以下の通りです： - 「私たちの開発フローにおいて重要なボトルネックを示す課題は何か？」 - 「成功に必要な主要な依存関係をコントロールできているか？」 - 「既存のワークフローに最小限の影響を与えてこの変更を実施できるか？」 制約は、他の改善に関係なくシステムのパフォーマンスを制限するボトルネックです。たとえば、すべてのリリースに時間のかかる手動のセキュリティレビューが必要な場合や、限られたGPU容量がチームのAIソリューションの開発とテスト能力を制限している場合、これらの制約に対処することで複数のワークフローにわたって価値を解放することができます。 同様に、AIによるコード生成ツールが新たなボトルネックを生み出している場合があります。例えば、AI生成コードの品質に関する懸念からコードレビューサイクルが長くなることや、特定のAIサービスへの依存がパフォーマンスの障害となることです。これらのAI関連の制約は、優先順位を付ける必要があるかもしれません。制約を評価する際は、頻度と影響の両方に基づいて優先順位を付けることが重要です。毎日すべての開発者に影響を与えるプロセスは、たとえ四半期ごとに発生する劇的なボトルネックよりも、累積的な摩擦を生むことが多いです。後者は大きな不満を引き起こすことがありますが、頻繁に発生する制約を排除することは、コアのボトルネックに対処しない小さな改善を複数実施するよりも、生産性をより効果的に引き出すことができます。最も価値のある開発者体験（DevEx）の改善は、新しい機能を追加するのではなく、制約を取り除くことから生まれることが多いです。 CloudTechの制約評価： - 手動デプロイ：高 — すべての機能がデプロイキューで待機し、リリース頻度が制限される。 - ビルド時間：高 — 開発者は90分のビルド中にコンテキストスイッチを行い、すべての作業が遅くなる。 - 不安定なテスト：中 — チームは失敗を回避できますが、リリースは依然として遅れる。 - ローカル環境：低 — 個々の生産性には影響しますが、設定後はチームのワークフローを妨げません。 - オンボーディングドキュメント：低 — 新入社員や内部異動者にのみ影響し、継続的な開発には関係ありません。 チームや組織の要因も忘れないでください。「どの課題が、技術的な問題を解決しながら私たちの人材と組織を強化することができるか？」と自問してみてください。チームメンバーが専門知識を活かしながら成長と認識の機会を創出できるプロジェクトを探しましょう。最も成功する取り組みは、チームの専門的な成長の関心やインセンティブと一致しています。 CloudTechのチーム目標評価： CloudTechは「私たちのチームの成長とインセンティブに合致するものは何か？」と尋ねました。 - 手動デプロイ：高 — チームが学ぶことに興奮している専門知識を必要とする興味深いDevOps作業。 - ビルド時間：低 — 深いアーキテクチャの知識が必要で、数人のチームメンバーしか持っていない。 - 不安定なテスト：高 — シニアエンジニアがデバッグスキルやテストの専門知識を披露することに興奮。 - オンボーディングドキュメント：高 — 新しいチームメンバーに意味のある貢献とオーナーシップを与える。 - ローカル環境：中 — 良い学習機会だが、ルーチンのコンテナ化作業。 他の考慮事項も忘れないでください。上記の例は包括的ではなく、組織特有の基準を含める必要があります。例えば： - リモートワークフォース：「リモートワークに不均衡に影響を与える最初に取り組むべき課題は何か？」 - AI導入：「AIツールが生み出している摩擦は何で、それに対処する必要があるか？」または「AIツールの導入を妨げている課題は何か？」 - 規制が厳しい業界：「最も規制上の摩擦を生む課題は何か？」 あなたの優先順位付けの演習は、二重の役割を果たすことができます。ツールや自動化の優先順位を付けるために使用する評価基準は、データの計測やフィードバックループへの投資を導くためにも使用されるべきです。 高優先度の開発者の摩擦ポイントを評価フレームワークを通じて特定すると、測定のための重要なターゲットも見つけることができます。これにより、強力な相互利益が生まれます。もし高優先度の摩擦ポイントが見つかったのに、システムデータがない場合、それは警告信号です。ツールの改善とシステムの計測を同時に進めるべきです。例えば、最も使用されているCIパイプラインにパフォーマンス追跡がない場合、そのギャップを埋めると同時にパイプラインを改善する必要があります。また、計測を構築している間に洞察を得るためのターゲットを絞ったアンケート質問を追加することもできます。アンケートの回答がシステムで見えるものと一致しない場合、私たちの経験やGoogleの生産性研究者の発見によれば、矛盾があるときは自己報告データが通常正しく、隠れた痛点を指摘することが多いです。次回の開発者アンケートには、より多くの情報を得るためにターゲットを絞った質問を追加することをお勧めします。例えば、開発者がデプロイに時間がかかると言っているのに、ログにそのような情報が表示されない場合、より良いツールと追跡が必要です。 リソースが限られている場合でも、最も摩擦の大きい領域には、より良いツールとより良い指標が必要です。測定できない問題に対してツールを構築しても、改善、影響、ビジネス価値を示すことは非常に難しいです。試してみてください：あなたのトップ3のDevExの痛点について、「この領域の改善を測定できますか？」と尋ねてみてください。もしできない場合は、ツールの改善と同時に測定戦略を計画しましょう。このアプローチは健全なサイクルを生み出します。より良い測定がより良いツールの構築を助け、より良いツールがより有用なデータの収集を可能にします。この体系的なアプローチは、ステップ3で収集したデータに基づいており、ステークホルダーとのコミュニケーションに備えるためのものです。 次に、全体像を把握するために、迅速なルブリックを使用しましょう。細部に迷い込むことを避け、大局を見つめることが重要です。データを収集した結果、トップのDevExの課題、RICEスコア（リーチ、影響、信頼度、努力を定量化したもの）、および「どの課題を最初に取り組むべきか？」という質問から得た追加の評価が揃ったら、大局を見つめる準備が整いました。ルブリックを作成しましょう。まずは、あなたの組織にとって最も重要な基準から始めます。第27章の分析に基づくと、一般的なDevExの優先順位付け基準には以下が含まれます： - RICE分析はビジネス価値にマッピングできる。 - 集団的な行動を必要とする。 - ビジネスのタイムラインやリズムに沿っている。 - 制約がある。 - チームの目標に沿っている。 - [あなたの文脈に特有の質問をここに記入してください。] ルブリックを作成し、埋めたら（この作業は同僚と一緒に行うべきです）、いくつかの重要な課題が浮かび上がってくるはずです。すべてが高優先度であれば、再評価を行ってください。すべてが最高優先度という世界では運営できません。すべてが低優先度であれば、再評価を行い、異なる視点を考慮してください。詳細なルブリックはステップ4のワークブックにあります。 CloudTechの完了した分析を見てみましょう。CloudTechのRICE分析と追加の基準がどのように戦略的ルブリックに変換されるかを見てみましょう。RICE分析を含めました。 第27章で概説したスコアとDevEx基準に基づいて、CloudTechは手動デプロイメントから始めることを決定しました。これは、ビジネス価値が高く、RICEスコアも最も高いためです。また、オンボーディングドキュメントも迅速な成果を得るための手段として選ばれました。ビルド時間はビジネス価値とRICEスコアが高いものの、タイムラインの制約があるため、最初の2つの取り組みで成功を収めた後に取り組むことにします。 RICEとDevEx基準を組み合わせた際の重要な洞察は以下の通りです： - RICEは彼らの直感を裏付けました。手動デプロイメントは最高のRICEスコア（1,275）を持ち、戦略的基準でも高い評価を得ています。 - タイムラインの考慮が優先順位を変えました。ビルド時間は2番目に高いRICEスコア（183）を持っていましたが、タイムラインの制約が早期の取り組みとしては不適切であることを示しました。 - 迅速な成果が明確になりました。オンボーディングドキュメントは、RICEスコアが最も低い（53）にもかかわらず、高いタイムラインスコアとチームの整合性により、価値のある並行トラックとして浮上しました。 分析を最大限に活用しましょう。RICEスコアと戦略的ルーブリックの組み合わせは、以下の視点を提供します： - RICEスコアを定量的な正当化、ROI計算、詳細なリソース計画に使用します。 - ルーブリックは戦略的コミュニケーション、ステークホルダーの整合性、大局的な意思決定に使用します。 - もし両者が対立する場合は、RICEの入力を調整する必要があるのか、タイムラインやチームのキャパシティといった戦略的要因が数値的最適化を上回るべきかを考慮します。 目標は数学的な完璧さではなく、定量的な影響と組織の現実をバランスさせた情報に基づく意思決定を行うことです。明確な戦略と優先順位を持つことは重要ですが、それだけでは不十分です。どんなに考え抜かれたDevExのロードマップでも、効果的なコミュニケーションとステークホルダーのサポートがなければ失敗します。次の章では、あなたのDevEx戦略を組織内でどのように売り込むか、異なるオーディエンスにメッセージを調整し、持続的な変化を推進するために必要なサポートを構築する方法を示します。 ステップ5：戦略を売り込む 完璧なDevEx改善計画は、誰も何をすべきか、なぜ気にすべきかを知らなければ意味がありません。改善計画の戦略と優先順位を確立した今、これらの決定をどのようにコミュニケーションし、組織全体でサポートを得て行動を促すかに焦点を当てる時です。効果的なコミュニケーション（以下「コミュニケーション」と呼びます）は、開発者が直面する摩擦の原因、これらの痛点に対処することがなぜ重要なのか、摩擦を取り除くことで期待される価値、そして計画している具体的な行動を説明します。 最良いDevEx（開発者体験）コミュニケーションは、より遠くまで届きます。それは、インタラクティブなワークショップ、メンタリングプログラム、実践的な体験を通じて、ステークホルダーの能力を高め、持続的な行動変容を生み出します。しかし、多くのDevExチームは、戦略的コミュニケーションの重要性を過小評価しています。アマゾンやスポティファイのような先進企業は、DevExイニシアティブのために専任のマーケティングおよびコミュニケーションチームに投資していますが、能力構築やステークホルダーの支援を含め、小規模な組織でも技術ライターやプロダクトマネージャーがこの重要な分野に焦点を当てることで、同様の成果を上げることができます。 第28章 ステークホルダー分析を活用した効果的なコミュニケーション あなたが構築した関係や、リスニングツアーで得た洞察は、各グループに響くメッセージを作成するのに役立ちます。ステップ1で完成させたステークホルダーマトリックスを思い出してください。今こそ再びそれを引き出す時です。初期の特定作業は、あなたのコミュニケーション戦略の基盤を提供します。ステークホルダーは単なる開発者以上の存在であることを忘れないでください。多くの人がDevExコミュニケーションプランの対象は開発者だと考えますが、その考えはしばしば誤りです。開発者はこれらのイニシアティブから恩恵を受けますが、彼らはあなたのコミュニケーションプランの主要な対象ではありません—少なくとも最初はそうではありません。DevEx改善イニシアティブはしばしば組織全体の支援とリソースを必要とするため、あなたの主要な対象は、あなたの支援が必要で望ましい組織のリーダーたちです。ステップ1のステークホルダー分析では、各グループの関心レベル、DevExの概念への親しみ、一般的な支持度を特定しているはずです（もしそうでない場合は、今すぐ戻って空欄を埋めてください）。この情報を活用して、コミュニケーションを形作り、優先順位を付け、どのステークホルダーがより詳細な関与を必要としているかを判断します。 ステークホルダーの特性に基づいてアプローチを調整します。異なるステークホルダーには異なるコミュニケーションアプローチが必要ですので、メッセージをそれに応じて調整する必要があります。よくある誤りは、全員に同じメッセージを送信することで、結果として経営者には技術的すぎる内容になったり、実務者には十分な詳細が欠けたりすることです。すべてのステークホルダーに同じコンテンツを一斉送信すると、圧倒的で不完全なメッセージを作り出すリスクがあります。開発者は実装に関する質問が残るかもしれませんし、リーダーは技術的な詳細から戦略的価値を引き出すのに苦労するかもしれません。代わりに、リスニングツアーから得た洞察を活用して、ターゲットを絞ったコミュニケーションを作成します。技術チームには実装の具体的な内容やワークフローへの影響に焦点を当て、リーダーシップにはビジネス成果やリソースの考慮事項を強調します。人事や財務などの隣接部門には、彼らの領域に関連する指標を強調し、その指標がどのように彼らに関連するかを説明します。このターゲットを絞ったアプローチにより、各ステークホルダーは自分の特定の懸念に対処する情報を受け取り、適切な行動を促されます。 コミュニケーションに特化した詳細でステークホルダーリストを洗練させましょう。 ステップ1のステークホルダーマトリックスを見直し、コミュニケーションの好みを含めて拡張しましょう。各グループにとって最適なチャネルは何か、重要な指標は何か、彼らの優先事項に響く言葉は何かを考えます。このアプローチにより、開発者から経営者まで、すべてのステークホルダーに共鳴するようにコミュニケーションを調整できます。パートIIIで探求したビジネスケースの要素は、このポジショニングの基盤を提供します。ステップ1のワークブックには、例となる表が用意されています。重要なステークホルダーと情報を表やスプレッドシートにリストアップすることが役立つことが多いです。これは、整理のためだけでなく、特定のステークホルダーグループに対して不足している情報を特定するのにも便利です。あなたのステークホルダーと収集する情報は異なります。ここでは、主要なステークホルダー、その動機（なぜ彼らが関心を持つのか）、必要なサポートレベル（懐疑的、中立、熱心）、エンゲージメント戦略（情報提供、説得、協力）、情報ニーズ、エンゲージメント戦略、および好ましいコミュニケーションチャネルを特定します。以下はシンプルな例です。 通常、3つまたは4つのステークホルダーグループがあり、リーダーシップ、エンジニアリングマネージャー、開発者に大まかに分類されます。組織の規模やチームの協力の仕方によっては、「情報提供を受ける」グループとしてカスタマーサポート、マーケティング、請求部門などのチームが追加されることもあります。これらのチームは開発者ツールに強く依存しており、何が起きているのか、どのように彼らの仕事に影響を与えるのかを把握しておきたいと考えています。メッセージを簡素化し、ターゲットを絞るためには、グループを多く持たないようにしましょう。この表を使えば、必要なときにターゲットを絞ったメッセージを送るための情報が常に手元にあります。ステップ5のワークブックには、使用できる資料が含まれています。 ステークホルダーを特定することは、DevEx改善イニシアチブの初期段階で協力したい特定のグループを見つけるのにも役立ちます。たとえば、高摩擦のプロビジョニングが課題である場合、プロセスを改善する方法を試行錯誤している組織内のチームがいるかもしれません。彼らは技術的にも文化的にも素晴らしいパートナーとなるでしょう。一方、レガシーソフトウェアに取り組んでいるチームはこの問題を全く抱えていないかもしれず、イニシアチブが彼らのツールやワークフローに影響を与えるまで、情報提供を受けることにしか関心がないかもしれません。 あなたのステークホルダーは、問題が何であり、なぜ彼らが関心を持つべきなのかを知る必要があります。すべての人があなたの組織が直面しているDevExの問題を、あなたと同じように明確に理解しているとは限りません。人々は多様なバックグラウンドを持っており、それが彼らのシステムに対する良い、悪い、あるいは可能なことに対する見解を形成しています。 一部の利害関係者は、あらかじめ解決策を持っているかもしれません。たとえば、経営陣はAIツールを導入すれば自動的に開発者の生産性の課題が解決されると考えることがありますが、AIの限界や最初に対処すべき具体的な摩擦点を理解していないことが多いです。開発者が直面している問題を明確に示し、それが各利害関係者にとってなぜ重要なのかを説明する時間を取りましょう。特に普段あまり関わりのないグループに対しては、最初は難しいかもしれません。DevEx（開発者体験）を改善することが各利害関係者にとってなぜ重要なのかを理解することが大切です。これにより、効果的に説明し、共感し、さらに学ぶことができます。もし誰かとのつながりを見つけられない場合は、その人をリストから外すか、彼らに影響を与える可能性のある作業を将来のサイクルに移すことを検討してください。 利害関係者とのコミュニケーションにはEMIフレームワークを活用しましょう。DevExに関するコミュニケーションを作成する際には、EMIフレームワークを適用して、各利害関係者グループにメッセージが響くようにします。 E = 教育（Educate）：彼らの役割や視点に特有の知識のギャップに対処します。 M = 動機付け（Motivate）：DevExの改善を彼らの優先事項や痛点に結びつけます。 I = 情報提供（Inform）：彼らの関与に関連する実行可能な詳細を提供します。 これらの要素は、各利害関係者のサポートレベルや情報ニーズに基づいて調整する必要があります。熱心な支持者には強化やチャンピオンとしての機会が必要であり、懐疑的な人々には追加の証拠やリスク軽減が求められます。中立的な利害関係者は、明確な価値提案や成功事例に反応することが一般的です。 例えば： | 対象者 | 教育 | 動機付け | 情報 | | --- | --- | --- | --- | | 開発者 | 「私たちの分析では、ビルド失敗の40%が設定の問題から生じています。」 | 「この取り組みにより、ビルド時間が30%短縮され、手動での回避策が不要になります。」 | 「次のスプリントから新しいビルドシステムを導入します。トレーニングセッションは木曜日に行います。」 | | エンジニアリングリーダー | 「チームは毎週15時間、避けられる技術的負債に費やしています。」 | 「これらの問題に対処することで、機能の提供速度が25%向上する可能性があります。」 | 「Q3の2週間のクリーンアップスプリントを優先する必要があります。」 | | HRリーダー | 「エンジニアは20%の時間をビルド待ちやインフラの問題に費やしています。」 | 「システムの改善により、離職率が15%減少する可能性があります。」 | 「あなたが四半期のエンゲージメントレポートに組み込める開発者満足度の指標を追跡します。」 | | 財務 | 「現在の非効率なシステムは、年間450Kドルのコストがかかります。」 | 「この取り組みにより、クラウドコストが削減される見込みです。」 | 「次の四半期の予算で、9か月の移行に必要な追加の承認が必要です。」 | EMIを適用することで、利害関係者に何が起こっているかを知らせるだけでなく、それがなぜ重要なのかを教育し、彼らの特定の優先事項に沿った利益で動機付けることができます。特に新しい取り組みを発表する際には、興奮して「私たちはこれを実現しました！」というメッセージを全員に送信したくなる気持ちを抑えることが重要です。 その祝賀はあなたのチームや直属の管理者と共に行うべきですが、他の利害関係者には、成果よりも影響に焦点を当てたEMI構造のコミュニケーションが必要です。あなたのDevExイニシアチブを製品のように考え、利害関係者に「売り込む」ことを意識しましょう。DevEx改善イニシアチブについてコミュニケーションを行う際には、製品の視点を取り入れることで、メッセージをより魅力的にすることができます。このアプローチは以下の点で役立ちます： - 単に技術を実装するのではなく、特定の問題を解決することに焦点を当てる。 - 利害関係者が理解できる形で価値を明確に伝える。 - イニシアチブの目的と利点について、一貫したストーリーを作成する。 「投資家」（あなたの仕事に資金を提供するリーダー）には、ビジネスケース、競争環境、期待されるリターンを簡潔に説明できる必要があります。「顧客」（開発者やエンジニアリングマネージャー）には、あなたのソリューションが彼らの具体的な課題にどのように対処するかを強調する必要があります。この製品ベースの枠組みは、「開発者体験の向上」といった抽象的な概念を、利害関係者が容易に理解し支持できる具体的なソリューションに変換します。DevExツールや自動化エコシステムを製品として扱うための詳細なアプローチについては、「第三の実践：技術を持続可能で効果的にする」を参照してください。 ### 効果的なメッセージングにはカスタマイズと繰り返しが必要 各グループに合わせてメッセージを形作ることで、支持を得て人々を巻き込むことができます。開発者の課題とそれがあなたの聴衆にとってどのように関連するかを共有する際、単に情報を提供するのではなく、彼らを解決策の重要なプレーヤーとして招待しているのです。いくつかのコアメッセージは利害関係者グループ全体で一貫性がありますが、以下の質問を考慮してアプローチを調整しましょう： - この特定のグループに対するメッセージのトーンは適切か？ - 技術的な詳細のレベルは適切か、それとも言葉を簡素化すべきか？ - 問題や潜在的な改善を示すために具体的な例を提供する必要があるか？ - これが彼らの仕事にどのように直接影響するか？ - 具体的に何を求めているのか—支援、情報、擁護、リソース？ 各グループ向けにメッセージをドラフトし、主要メンバーと共有してトーン、内容、配信チャネル（例：メール対内部投稿）をレビューし最適化することをお勧めします。人々に何が起こっているかを伝え、何度も言いましょう。私たちは皆、見逃されたり、アーカイブされたり、無視されたりするメールやSlackメッセージを経験しています—受信トレイがいっぱいで追いつくのが難しいことがあります。あなたのDevExコミュニケーションも同じ課題に直面しているため、特に開発者を対象とする際には、重要なメッセージを複数回共有する計画を立てましょう。リーダーシップ向けのコミュニケーションでは、焦点を絞ったメールの後に、会議中に簡潔なプレゼンテーションを共有するのが効果的です。これらの資料は転送される可能性が高いことを忘れず、独立して成立し、一目で理解しやすいコンテンツを作成しましょう。エンジニアリングマネージャーや開発者とコミュニケーションを取る際には、最初にDevExチームからメッセージを送信し、その後リーダーに1週間後にリマインダーを送ってもらうように依頼することを試みてください。この二段階のアプローチは、効果的なコミュニケーションを促進します。 ステップアプローチは、メッセージの重要性を強調するだけでなく、経営陣がその取り組みを支持していることを示します。このリーダーシップによるフォローアップの後には、ツールの採用率やアンケートの完了率が顕著に上昇することが一貫して見られます。これは、DevExコミュニケーションにおいて、考慮された繰り返しが冗長ではなく、効果的であることを証明しています。 あなたのDevExイニシアティブにアイデンティティを与えましょう。人々を活気づけるような記憶に残る直感的な名前やアイデンティティでDevExイニシアティブをブランディングすることを検討してください。シンプルでキャッチーな名前は、全員に共通の参照点を提供し、あなたの取り組みに対する興奮を生み出すことができます。このブランディングに加えて、DevExイニシアティブに関連する用語の簡単な用語集を作成し、成功を示す重要な指標を共有しましょう。これにより、明確さが生まれ、チームが全体の中で自分たちの位置を理解しやすくなります。 他の人が自信を持って情報を広められるように、より多くの資料が必要です。ワークショップや詳細な参考資料などの追加資料は、リーダーや他のステークホルダーに特に役立つかもしれません。一方、開発者グループには、技術的なランブックやFAQセッションが有用です。 能力を育てること、ただの認知を超えて。効果的なDevExコミュニケーションは、人々に情報を提供するだけでなく、彼らがあなたのイニシアティブを理解し、関与し、支持する能力を構築します。資料を設計する際は、ステークホルダーを次の三段階の進行に導くようにしましょう： + 理解する。彼らは全体像、価値、DevExの重要性、基本用語を把握します。 + 試す。彼らは学んだことを使ってアイデアに関与し、あなたの取り組みを支援し、促進する方法を積極的に探ります。 + 活性化する。彼らは他の人を指導し、チーム内での能力を構築し、DevExイニシアティブを持続的に改善するための提案を行います。 このフレームワークは、一時的な認知ではなく、持続的な変化を生み出すコミュニケーションを作成するのに役立ちます。ある例では、私たちはHRパートナーを詳細な参考書とワークショップで支援しました。ホワイトペーパーでは、技術的な概念（開発者の摩擦やプラットフォームエンジニアリングなど）を彼らの領域に関連付け、DevExイニシアティブが採用、トレーニング、保持にどのように影響するかを説明しました。これらの技術的な詳細はHRの一部の人にとって新しいものであったため、DevExの変更においてエンジニアリングチームを支援するシナリオを練習できるインタラクティブなワークショップを提供しました。この実践的なアプローチにより、HRパートナーはDevExの作業における技術的な状況を自信を持ってナビゲートできるようになりました。 Snowflakeがコミュニケーションを通じて開発者の信頼を再構築した方法。Snowflakeのエンジニアリングシステムチームが広範な不信感に直面したとき、エンジニアたちは「誰も聞いていない」と信じていました。彼らは、認識を変えるためにはコミュニケーションが重要であることを理解していました。彼らの解決策は、繰り返しと開発者のニーズに応えることを強調した包括的なマルチチャネルアプローチでした。彼らの戦略には、毎週のCTOによるメトリクスの更新、隔週のニュースレター、四半期ごとのアンケート、各チームの全体会議でのロードショーが含まれていました。 調査への参加率は、1,200人のエンジニアの間で40〜50％に達しました。参加を促すために、DevExチーム、チームディレクター、エンジニアリング部門の責任者、CTOなど、さまざまなレベルからの働きかけを調整しました。重要な洞察は、新しいソリューションの導入を促進する最良の方法は、開発者がいる場所で彼らに寄り添うことだということです。複数のチャネルで一貫したメッセージを発信し、ベルリンでの週次全体スタンドアップのような場所特有のアプローチを組み合わせることで、組織の認識を成功裏に変革し、持続的かつ戦略的なコミュニケーションを通じて信頼を築きました。 「失礼なFAQ」を用意して、難しい質問に備えましょう。私たちがコミュニケーションの準備に役立てているツールの一つが「失礼なFAQ」です。これは、人々が尋ねるかもしれない質問をいくつかリストアップした文書で、通常は防御的または議論的なものです（例えば、「開発者はすでにこれをやっているのでは？」や「なぜこれらの指標を選んだのか、私の考える生産性とは違う。」など）。この技術はプロダクトマネジメントから借用したもので、チームが反論を予測し、必要になる前に考え抜かれた回答を用意するのに役立ちます。この文書を作成することで、チームが難しい質問に対する回答を一致させ、重要なプレゼンテーションや会議で不意を突かれることを防ぎます。また、質問や懸念を予測することで、コミュニケーションを改善する助けにもなります。 失礼なFAQを作成する際には、チームの率直な回答を含めつつ、それを建設的で証拠に基づいた回答に洗練させ、懸念を認めつつもあなたの取り組みの価値に話を戻すようにします。この文書はDevExチーム専用で、会議やメールで受ける可能性のある質問に備えるためのものです。また、利害関係者が抱える懸念を特定するのにも役立ちます。 DevEx戦略が明確に伝えられ、利害関係者の支持が得られたら、変更を実施する準備が整います。しかし、取るべきアプローチは、組織内での影響範囲に応じて調整する必要があります。次のステップでは、チームレベルであれ全社的であれ、DevExの改善を効果的に推進する方法を探ります。 STEP 6 あなたのスケールで変化を推進する あなたの戦略は設定され、優先事項は明確で、利害関係者とのコミュニケーションも効果的に行われています。今、実際に変化を実施するための重要な作業が始まります。この章では、あなたのコントロールの範囲に合わせたアプローチをどのようにマッチさせるかを示し、組織の慣性と戦うのではなく、最も早く影響を与えられる場所に焦点を当てます。開発者体験を改善するための努力が成功するための最も重要な要素の一つは、あなたのアプローチがコントロールの範囲にどれだけ合致しているかです。あなたがDevExの責任者で組織的な権限を持っている場合でも、チームの日常業務を改善しようとするエンジニアであっても、コントロールの範囲を理解することで、取り組むべき適切な問題を選び、変化を推進する最も効果的な方法を見つけることができます。 第30章 アプローチを調整する あなたのコントロールの範囲に合わせて 自分のコントロールの範囲内にある領域をターゲットにすることで、より早く影響を与えることができます。組織の慣性と戦うために時間を無駄にせず、実際に変化を促進できる場所に焦点を当てましょう。DevExにおけるコントロールの範囲とは、改善を直接影響を与え、実施する能力の幅を指します。グローバルなレベルでは、正式な権限や専任のリソース、組織全体の変革を推進するための任務を持っているかもしれません。例えば、CIプラットフォームの再構築や、複数のチーム間での新しいコラボレーションの実践を確立することなどです。一方、ローカルなレベルでは、自分のチームや少数のチームの中で作業し、広範な組織の変更や大規模なリソースを必要とせずに実施できる改善に焦点を当てることになります。効果的なDevExの作業の原則は、範囲に関係なく同じです。これらの原則には、実際の問題に焦点を当てること、技術的な変化と文化的な変化のバランスを取ること、影響を測定することが含まれます。変わるのは、これらの原則をどのように適用し、採用を促進し持続的な影響を生み出すために使用する戦略です。グローバルおよびローカルの両方のレベルでDevExの改善を実行する方法を探っていきます。以下のことを学びます： - コントロールの範囲に合ったプロジェクトを選ぶ。 - 異なる組織レベルでのサポートを構築し、採用を促進する。 - 各範囲に特有の一般的な失敗パターンを避ける。 - 技術的改善、プロセスの変更、文化的シフトの相互作用をナビゲートする。 - 成功を活用して、コントロールの範囲を拡大する可能性を探る。 これらの違いを理解することで、問題の特定から実際の解決に移行する手助けとなります。全体の組織で作業している場合でも、自分のチームから始める場合でも同様です。 第31章 グローバルなコントロールの範囲で変化を推進する グローバルなコントロールの範囲とは、組織のサポートと任務を持っていることを意味しますが、成功は依然として広範な行動を推進することに依存します。この章は、DevExの責任者やシニア技術リーダーのようなリーダー向けです。彼らは組織全体の改善を推進するための公式な権限とリソースを持っています。役職やリーダーシップのサポートがあっても、実際の影響を生み出すためには異なるチーム間での協力が必要です。ステップ3で採用したデータ収集のアプローチは、この規模での進捗を追跡するために特に重要です。グローバルな範囲での最大の課題は技術的なものではなく、正しい問題を選び、持続可能な変化を推進することです。組織の支援があっても、成功には単により良いツールを構築する以上のものが必要です。内部のCIシステムを再構築する場合を考えてみてください。最も洗練されたプラットフォームを作成することはできますが、チームがそれを採用したり効果的に使用しなければ、開発者体験は実際には改善されていません。グローバルなDevExイニシアチブが典型的に失敗する方法は2つあります。1つ目は、完璧な技術的実行で間違った問題を解決することです。 これは、チームが以下のような状況にあるときに起こります： - 実際の問題を検証せずに解決策を構築する（これは以前に触れたことです—このステップを飛ばさないでください！） - 開発者が何を必要としているかを既に知っていると仮定する。 - 一度にすべてを解決しようとするのではなく、段階的な価値を示す。 次の方法は、適切な問題を優れた技術で解決することですが、変革管理に失敗することです。これは、チームが以下のような状況にあるときに起こります： - 「作れば、彼らは来るだろう」と仮定する。 - 導入戦略やコミュニケーションに十分な投資をしない。 - 技術的な改善にのみ焦点を当て、プロセスの変更を無視する。 - 文化的な変化を促進し、持続させる方法を考えない。 効果的な技術的改善には、強力なプロセスと文化的な受け入れが必要であり、これが実際の影響を生み出します。成功したグローバルなDevExの改善が、技術、プロセス、文化という3つの重要な要素をどのように組み合わせているかを、改善されたCIシステムの導入という観点から見てみましょう。技術的な実装は完璧かもしれません—ビルドが速く、キャッシュが改善され、テストインフラがより信頼性の高いものになっているかもしれませんが、それは始まりに過ぎません。技術的な基盤は、開発者に明確な価値を提供する必要があります。特定のチームのニーズに合わせたローカルな改善とは異なり、グローバルな技術的変更は、さまざまなシナリオで機能する必要があります。あなたの解決策は、組織全体のさまざまなユースケースに対応できるように、強力でありながら柔軟でなければなりません。たとえば、ウェブアプリケーションには完璧に機能する新しいCIシステムが、特定のハードウェア要件を持つモバイルビルドには対応できない場合、広範な採用は達成できません。以下はいくつかの追加例です： - モダンなビルドインフラストラクチャ。 - テストの実行と信頼性の向上。 - より良いキャッシュと並列処理。 - 明確なメトリクスとモニタリング。 グローバルなソリューションへの2つのアプローチ。組織全体のツールを構築する際には、すべてのエッジケースを処理できる柔軟なプリミティブを作成するか、最も一般的なシナリオをより少ない複雑さで解決する意見を持ったプラットフォームを構築することができます。最良のシステムは、しばしば両方を組み合わせています：80パーセントのケースに対するシンプルなデフォルトと、特別な要件を持つチームのための柔軟性です。プロセスの変更は、ソリューションが使用できることを保証します。ここが多くのグローバルなイニシアチブがつまずくところです—彼らは素晴らしい技術的解決策を構築しますが、それをアクセス可能で採用可能にするための投資が不足しています。たとえば、遅くて信頼性のないリリースを解決するために新しいデプロイメントプラットフォームを構築するチームの例を考えてみましょう。このプラットフォームはデモでは美しく機能しますが、チームは特定のユースケースに合わせてそれを設定するのに苦労し、移行に関するドキュメントは不完全で、明確なサポートプロセスもありません。技術的な解決策は存在しますが、採用の障壁が解決されなかったため、元の問題は依然として残ります。グローバル規模でのプロセスの変更は、異なるワークフロー、技術、制約を持つチームに対応する必要があります。たとえば： - チームが新しいシステムを既存のワークフローに統合するようにする。 - ビルド構成のための明確なガイドラインを確立する。 - チームが機能をリクエストしたり問題を報告したりするためのプロセスを作成する。 - サポートチャネルとドキュメントの整備。 - 異なるプロジェクトタイプに対する移行パスの定義。 文化的な変化は、改善を定着させ、広めるために重要です。グローバルな規模での文化的変化は、より困難でありながら、より重要でもあります。あなたが変えようとしているのは、単に一つのチームの仕事に対する考え方ではなく、組織全体の実践やマインドセットをシフトさせることです。例えば、あるチームは、ビルドを壊した人がすぐに修正しなければならないというポリシーを導入しました。しかし、適切なツールがなければ、これはより良い実践を生むのではなく、ただストレスを増やすだけでした。文化的な変化には、一貫した努力と価値の明確な示しが必要です。例えば： - 新しいシステムの信頼性に対する信頼を築くこと。 - チームがビルドを常に成功させることを優先するようにすること。 - CIからの迅速なフィードバックを重視する文化を育むこと。 - チームがプラットフォームに改善を貢献することを奨励すること。 明確な技術基盤、プロセスの変更、文化的要素があっても、それだけでは不十分です。これらを展開するためには、意図的な戦略が必要です。成功するグローバルなDevExの改善は、「ビッグバン」アプローチではほとんど成功しません。代わりに、小さく始め、焦点を絞ったパイロットを通じて価値を証明し、慎重な実行と強い関係を通じてスケールアップします。 まずは、協力的な人々の連携を築くことから始めましょう。グローバルなイニシアティブの初期段階は、勢いと信頼性を築くために重要です。全員を一度に説得しようとするのではなく、問題を理解し、解決を手助けしたいと考えている人々を見つけて支援することに焦点を当てましょう。例えば、ビルドの失敗に毎日3時間を費やしているモバイルチームは、熱心な早期採用者になるでしょうが、5分でビルドが完了する小さなプロダクトチームはあまり興味を示さないでしょう。この焦点を絞ったアプローチは、より広範にスケールアップする前に、意欲的なパートナーと共に解決策を洗練するのに役立ちます。 特定された問題と提案された解決策を潜在的な利害関係者と共有します。最も痛みを感じているチームや支援的なリーダーを見つけましょう。彼らが最良のパイロット候補となります。影響力のある開発者や技術リーダーとつながり、彼らをチャンピオンに育てます。組織の障壁を取り除く手助けをしてくれる重要なリーダーとの関係を築きます。価値を証明し、アプローチを洗練するために焦点を絞ったパイロットを実施します。パイロットは、仮定を検証し、より広範な展開のための説得力のある証拠を構築する機会です。これは単に技術的な解決策をテストすることではなく、採用を促進し、チームを変化に対応させる方法を学ぶことです。 チームが新しいツールやプロセスを使って実験を設計し、実行する手助けをします。可能性を示すための迅速なプロトタイプを構築します。AIツールは、このプロトタイピングフェーズを加速させることができます。何が機能し、何が機能しないかについて具体的なフィードバックを収集します。AIツールの採用と効果を従来の開発指標と共に測定します。成功と課題の両方をオープンに文書化します。実際の使用に基づいて初期のテンプレートやプレイブックを作成します。開発者とリーダーシップの両方に響く方法で影響を測定します。 明確なコミュニケーションとコミュニティを通じて勢いを築きましょう。パイロットプロジェクトを超えて拡大する際には、解決策が機能することを証明することから、より広いオーディエンスにアクセスしやすく魅力的にすることに焦点が移ります。これには、採用に伴ってスケールできるサポートシステムの構築が必要です。 - パイロットチームからの具体的な成功事例や学びを共有しましょう。チームが経験を共有し、お互いに助け合うための場を作ります。 - 主要なステークホルダーとの定期的な接点を設け、整合性を維持します。 - 新しいチームが簡単に始められるよう、オンボーディングを容易にし、明確なドキュメントとサポートを提供します。 - 成功を収めているチームを祝福し、その成果を広めましょう。 パイロットチームから広範な採用への成長は、多くのDevExイニシアチブがつまずく重要な移行です。スケールでの成功には、優れた技術的解決策や初期の成功だけでは不十分です。増加する採用に対応しつつ、品質と勢いを維持できる堅牢なフィードバックループとサポートシステムが必要です。この移行を行うタイミングはチームにとってしばしば不明瞭ですが、信頼できるシグナルがあります。それは「フィードバックの収束」です。既存のパイロットユーザーから有用な新しい洞察が得られなくなったとき、拡大する準備が整ったことを意味します。ただし、それは自発的にフィードバックが現れるのを待つのではなく、積極的にフィードバックを求めていた場合に限ります。 すべてのレベルでの関与のための明確な道筋を作りましょう。 - パイロットチームとの定期的なチェックインを行い、進化するニーズを理解します。 - 開発者が問題を報告し、機能をリクエストできるオープンなチャネルを設けます。 - 技術リードやマネージャーからフィードバックを集めるための構造化された方法を用意します。 - 上級リーダーシップとの定期的なレビューを行い、整合性を維持します。 - チームが互いに助け合えるコミュニティスペースを設けます。 フィードバックを活用して継続的に改善し、拡大しましょう。 - チームの経験に基づいてプレイブックやドキュメントを定期的に更新します。 - 開発者とリーダーシップの両方に影響を示す指標を共有します。 - チームの成功や課題におけるパターンを特定します。 - 学んだニーズに基づいてスコープを拡大する機会を探ります。 - 技術、プロセス、文化の3つの要素をすべて継続的に改善し続けます。 採用に伴ってスケールするシステムを構築しましょう。 - 一般的なサポートリクエストやオンボーディングのステップを自動化します。チームが始められるようにセルフサービスリソースを作成します。 - 明確な所有権とサポートモデルを確立します。インフラストラクチャやサポートチャネルへの負荷増加に備えます。 - 技術的な詳細から変更管理のアプローチまで、すべてを文書化します。AI開発ツールやワークフローと統合します。 可視性と責任を通じて変化を促進します。「システムを操作する」という表現には否定的な意味合いがありますが、データを共有することで実際にポジティブな結果を生むことができるとしたらどうでしょうか？よく設計された指標は、リーダーやチームに間接的に影響を与え、組織の目標に向けたエネルギーを生み出すことができます。デイブ・アンダーソンがアマゾンでプラットフォームのエラー率を改善する責任を持つディレクターだったとき、彼は古典的な影響力の課題に直面しました。彼はエンジニアリングのロードマップに対する直接的な権限なしに変化を促進する必要がありました。彼の最初のアプローチは、マネージャーにエラー削減を優先するよう直接依頼することでしたが、失敗に終わりました。 これらのマネージャーは、主要な成果物に集中するようインセンティブが与えられており、上層部は問題の可視化ができていませんでした。デイブの突破口は、人間の心理を理解することから生まれました。彼は、以下の内容を含む月次エラーレポートを作成しました： - 各チームのエラー率をリスト化 - 各組織のオーナーを特定 - 責任者であるディレクターまたはVPを強調 このレポートは、CEOを含むアマゾンのエグゼクティブチーム（S-Team）に直接配布されました。「初めての月次レポートをS-Teamに送る前に、すべての組織にこの新しい報告方法について警告しました」とデイブは語りました。「今でも、あるディレクターが私のオフィスに駆け込んできて、『次のレポートが出るまでに、どれくらいの時間があるの？』と尋ねたのを覚えています。」 結果は劇的でした。リーダーたちは、リストの最下位に位置することを避けるために即座に動き出しました。エラー率は週ごとに急降下し、デイブのチームが一行のコードも書かずに実現しました。この取り組みは、OutlookとExcelを使って戦略的に設計されたメールで構成されていました。 あなたにとっての意味：経済的な論拠だけでは十分でない場合、競争のダイナミクスを利用することを考えてみてください。チーム間や業界のベンチマークと比較した重要な指標の可視化を作成しましょう。リーダーは、内部の仲間や外部の競合と比較される可能性に強く反応します。誰も自分のチームが最下位になることを望んでいません。 第32章 地域的なコントロールの範囲で変化を促進する 地域的なコントロールの範囲とは、広範な組織のサポートやリソースがなくても、意味のある改善を推進できることを意味します。この章は、チーム内で開発者体験を改善したいエンジニア、テックリード、エンジニアリングマネージャーのために主に書かれています。ステップ2のクイックウィンアプローチは、地域的な改善に特に関連しています。たとえグローバルな範囲を持っていても、ここでの戦略は価値があります。最も効果的なグローバルなDevExイニシアチブは、しばしばこれらのボトムアップ戦術を使用します：小さく始め、意欲のあるチームで実験し、具体的な結果を通じて価値を証明し、うまくいったものをスケールアップすることです。地域的な改善が成功する仕組みを理解することで、より良いパイロットプログラムを設計し、組織全体で草の根のイノベーションを支援することができます。 地域的な範囲での最大の課題は、スケールではなく、適切な戦いを選び、結果を通じて信頼性を築くことです。CIインフラ全体を再構築することはできないかもしれませんが、テストスイート、ドキュメント、開発ワークフローに焦点を当てた改善を通じて、チームの生産性を大幅に向上させることができます。 地域的なDevExイニシアチブが失敗する主な理由は2つあります。限られた範囲だからといって、重要な改善ができないわけではありませんが、努力の焦点をどこに置くかについて戦略的である必要があります。多くの善意の取り組みは、やりすぎてしまったり、成功をあまりにも制限してしまったりしてつまずきます。これらの失敗のパターンを理解することで、一般的な落とし穴を避け、影響を最大化することができます。 最初の失敗のポイントは、地域の範囲を超えた大きすぎる問題に取り組むことです。これは、チームが修正権限のないシステムを修正しようとしたり、他のチームとの大規模な調整を必要とする変更を引き受けたり、維持に多くのリソースを必要とするソリューションを構築したり、組織の承認や支援を待っている間に行き詰まったりする場合に発生します。これらの取り組みはしばしば熱意を持って始まりますが、すぐにチームのコントロールを超えた複雑さや依存関係に足を取られてしまいます。 次の失敗のポイントは、成功した改善をあまりにもローカルに留めてしまうことです。これは、チームが何がうまくいったのか、どのように実施したのかを文書化せず、共通の問題に対する解決策を共有する機会を逃し、効果的なプラクティスをチーム内に孤立させたり、成功した改善を拡大するための支援を構築できなかったりする場合に起こります。これらのチームは即座の問題を解決するかもしれませんが、その影響を拡大するチャンスを逃し、すでに解決した問題で他のチームが苦しむ様子を見守ることになります。ローカルな改善でも、成功するためには技術的、プロセス的、文化的な変化のバランスが必要です。小規模で作業しているかもしれませんが、効果的なDevEx作業の基本原則は変わりません。技術的な解決策だけでは持続せず、支援するインフラがないプロセスの変更は消えてしまいます。 これらの要素がどのように結びつくかを、一般的なローカルな課題である「チームのテストスイートの改善」という視点から見てみましょう。この例は、チームレベルの改善であっても、持続的な変化の3つの側面すべてに影響を与えることを示しています。技術的な基盤は、即座のチームの痛点に焦点を当てるべきです。チームが自分たちで実施し、維持できる改善から始めましょう。全体のシステムを再構築するようなグローバルな取り組みとは異なり、ローカルな改善は通常、既存のツールやワークフローの強化に焦点を当てます。例えば、あるチームは、テスト失敗の80％が外部ネットワーク呼び出しに依存する3つのテストから来ていることを発見し、それらの依存関係をモック化した結果、失敗率が5％未満に下がりました。テストフレームワーク全体を置き換えることはできないかもしれませんが、チームがそれをどのように扱うかを大幅に改善することは可能です。チームができる作業には以下が含まれます： - 不安定なテストを特定し修正する。 - テストのパフォーマンスと信頼性を向上させる。 - テストの組織化と命名を改善する。 - ローカルツールを使用してテストの作成とデバッグを支援する。 - AI支援開発のためのワークフローを最適化する。 プロセスの変更は、チームがより良いプラクティスを採用するのを助けます。技術的な改善がより良いテストを可能にする一方で、プロセスの変更はそれを実現可能にします。これらの変更は、チームがどのように協力して作業するかを定義し、共通の期待を確立します。例えば、あるチームはシンプルなチェックリストを作成しました。「このテストには明確な名前がありますか？一つのことをテストしていますか？独立して実行できますか？」これにより、テストレビューのコメントが70％減少しました。重要なのは、正しいことを簡単に行える軽量なプロセスを作成することです。考慮すべき重要なステップは以下の通りです： - 新しいテストを書くための明確なパターンを確立する。 - テストのカバレッジと品質に関するガイドラインを作成する。 - テストの品質を重視したコードレビューの実践を整備する。 + テストの問題を報告しやすく、修正しやすくする。 文化的な変化は、チーム内での改善が定着することを保証します。これは、地域的な改善の最も重要な要素かもしれません。文化的な合意がなければ、技術的な改善は無視され、プロセスは回避されてしまいます。例えば、あるチームは「テストの恐怖体験」を共有する週次セッションを始めました。ここでは、誰でも判断されることなく悪いテストを書いたことを認めることができ、協力的な解決策が生まれました。チームレベルでの文化的変化は、組織全体の変化よりも達成しやすいことが多いですが、それでも意図的な努力が必要です。この例では、 - テストの品質がなぜ重要なのかを共有理解する。 + チームが失敗したテストの修正を優先するようにする。 - 信頼性のあるテストスイートを維持することに誇りを持つ。 + テストの問題を報告し、議論することが安全であるようにする。 しかし、技術的、プロセス的、文化的要素の強固な基盤があっても、それだけでは不十分です。改善を実施するための実践的な戦略が必要です。地域的なDevExの改善は、チームが解決できる具体的な問題に焦点を当て、迅速に価値を証明し、同様の課題に直面している他のチームを助けるパターンを作り出すことで成功します。まず、問題に関してチームの調整を図ります。広範な組織の合意が必要なグローバルなイニシアティブとは異なり、地域的な改善には、直接のチームからの深い理解とサポートが必要です。この焦点を絞った範囲により、より豊かな議論ができ、問題に対する興奮を生み出し（それはチーム全体の共有のものです）、迅速に進めることができます。 - 日常業務における痛点とその影響についてオープンに議論する。 - 開発の摩擦に特化したチームの振り返りを行うか、次回のチームミーティングで「今週、何があなたを遅らせましたか？」と尋ねるために15分を割く。 - チームがどの問題に優先的に取り組むかを決定する際に関与させる。チームミーティングでドット投票を使用するか、影響と労力に基づいて痛点をランク付けできる共有ドキュメントを作成する。 成功がどのようなものかを共有理解する。これを一緒にワークショップ形式で行い、チームに理想的な開発日がどのようなものかを書き出させ、そのギャップを特定します。全員が解決策の形成に声を持つことを確認します。複数の入力チャネルを使用します：最初に調査や1対1のインタビューを通じて個々の視点を収集し、その後、集団で議論します。貢献しなかった人にフォローアップして、重要な視点を見逃していないか確認します。 - 懸念や代替アプローチのための安全なスペースを作る。 - 会議で悪魔の代弁者の視点を明示的に求め、敏感なトピックについては匿名のフィードバックチャネルを検討します。 チームとして小さな実験を行います。地域的な範囲の利点は、全員が新しいアプローチを試し、即座にフィードバックを提供できることです。この共同の実験は、解決策への投資を築き、問題を早期に発見するのに役立ちます。 - チームが試したいと思う軽量な変更から始めます。 + 明確なタイムフレームを設定し、評価に全員を巻き込みましょう。 + 異なる視点や働き方からフィードバックを集めます。 - データを使用して進捗やパフォーマンスを測定します。 + 何がうまくいったのか、何がうまくいかなかったのかを文書化し、チームの洞察を取り入れます。 + チームの実体験に基づいて調整する準備をしておきましょう。成功や学びを共有リソースとして文書化します。良い文書化は単に起こったことを記録するだけでなく、チームの集合的な知識と経験を捉えることです。この共有の歴史は、チームが時間をかけて改善を進化させるのに役立ち、他のチームにとってもより豊かなリソースを生み出します。 + 何をしたかだけでなく、特定のアプローチがチームにとってなぜ効果的だったのかも記録しましょう。 + 異なるチームメンバーの経験や洞察を追跡します。 - 多様なチームの視点を反映した実用的なガイドを作成します。 + チーム全体の影響を示す指標を集めます。 - 他のチームが学べるような協力的な改善のストーリーを構築します。 ローカルでのDevExの改善が成功すると、自然に広範な影響を与える機会が生まれることがよくあります。チームが共通の問題を効果的に解決すると、他のチームもそれに気づき、興味を持ちます。あなたの主な焦点は即座のチームを助けることかもしれませんが、あなたの成功は、同様の課題に直面している他のチームを自然に刺激し、助けることができます。 学びを共有する際には、協力や適応を促す方法を考えましょう。成功したパターンを広める鍵は、正確な解決策を指示することではなく、他のチームが自分たちの道のりを描けるように、あなたのチームの旅を共有することです。 + チームのストーリーを語る明確で実用的な文書を作成します。 改善をパッケージ化して実験を容易にします。何がうまくいかなかったのか、その理由も含めて文脈を示します。 課題についてオープンにし、チームがそれをどのように克服したかを示します。 - 実際の影響を示す具体的な例を提供します。 他のチームとの自然なつながりを築きます。改善を広める最も効果的な方法は、自然なチーム間の関係を通じてです。これらのつながりは、相互学習や適応の場を生み出します。 + エンジニアリングの議論の中で、チームのストーリーを非公式に共有します。 + 同様のフラストレーションを抱える他のチームとつながります。 - あなたの解決策が彼らの文脈にどのように適応できるかをブレインストーミングすることを提案します。 + チームが経験を共有する機会を作ります。 - 他のチームがあなたのパターンをどのように修正し、改善しているかから学びます。 組織の支援を求めるべきかを考慮します。時には、ローカルな改善が広範な投資から利益を得られるパターンを明らかにすることがあります。 組織の支援を求める最も説得力のあるケースは、実際のチームの成功から生まれることが多いです。改善がチームの日常業務にどのように影響を与えたかのストーリーを集めます。 他のチームがどのように自然に同様のパターンを採用しているかを文書化します。 組織の支援からどのような追加の価値が得られるかを特定します。草の根の勢いを理解しているリーダーとつながります。 自然な採用パターンが軽い支援でどのようにスケールできるかを示します。 ### 第33章 中間の立場で変化を促進する #### コントロールの範囲 一部のDevEx（開発者体験）役割は、グローバルとローカルの間に位置しています。あなたには権限があるものの、リソースが不足しているという状況です。これは、特に開発者体験の取り組みを正式に始めたばかりの組織においてよく見られる状況です。あなたは職名や名目上の経営陣の支持を持っているかもしれませんが、専任のリソースや確立された権限なしで活動しています。多くの成功したDevExイニシアティブは、このようにして始まります。この中間の立場で働くには、両方のスコープから戦略を組み合わせる必要があります。グローバルな権限を持っている一方で、インパクトを生み出すためにはローカルな戦術に大きく依存する必要があります。あるDevExリーダーは、チームが行った5分間の改善をデモするための月例のショーアンドテルランチを始め、いくつかのチームが互いの解決策を採用することにつながりました。 - すでに開発者体験を改善しているチームとの強い関係を築く。 - これらの散発的な取り組みをより一貫した物語にまとめる手助けをする。 - あなたの公式な役割を使って、成功したローカルな改善を広める。 - チームがうまくいっていることを共有するための軽量な方法を作成する。 - 異なるチームの取り組みから浮かび上がるパターンを文書化する。 この制約を利点に変える。限られたリソースを持つことはフラストレーションを感じるかもしれませんが、この立場には独自の機会があります。たとえば、新しいCIシステムを強制するのではなく、チームが現在の課題を比較し、どの改善を最初に試すかを共同で選ぶ手助けができます。あなたは、個々のチームが見逃すかもしれないパターンを見つけることができます。あなたの公式な役割は、異なる取り組みをつなげる権限を与えてくれます。チームは、あなたが解決策を押し付けていないため、協力する意欲が高まるかもしれません。具体的な成功を通じて、大規模な投資のための証拠を構築することができます。 + あなたが発見するパターンは、将来のグローバルなイニシアティブの基盤を形成することがよくあります。一部の改善は、どのスコープでも機能します。いくつかのDevExイニシアティブは、グローバルまたはローカルのスコープのいずれでも効果的に取り組むことができます。たとえば、集中して作業する時間を改善すること—中断のない開発時間を増やすこと—は目標として同じですが、実行はあなたのコントロールの範囲に応じて適応します。コアの原則は、スコープに関係なく一貫しています：問題を伝え、実験を行い、フィードバックを集め、学びを共有することです。変わるのは、これらの原則をどのように適用するかです。 グローバルなスコープでは、組織全体の開発者が会議に多くの時間を費やし、集中した開発時間が不足していることを特定します。あなたは次のようにするかもしれません： - リーダーシップと協力して、チーム間の会議パターンを分析する。 - 会議のない時間帯のガイドラインを作成する。 - チームが集中時間を改善するための実験を設計する手助けをする。 - 生産性への影響に関する組織全体のデータを収集する。 - 組織全体で成功したパターンを共有する。 ローカルなスコープでは、あなたのチームは会議に多くの時間を費やしていることを認識します。あなたは次のようにするかもしれません： - チーム内で「フォーカス・フライデー」を設ける。 - 専用の開発時間のためにカレンダーをブロックする。 - 定期的な会議を見直し、減らしましょう。+ チームにとって何が効果的かフィードバックを集めます。- 他の関心のあるチームと共有するために、アプローチを文書化しましょう。どちらの場合も、同じ核心的な問題を解決していますが、異なる規模や異なるレバレッジポイントで行っています。自分のコントロール範囲を理解することで、開発者体験を改善するための適切な戦略を選ぶ手助けになります。基本的な原則は変わりません—実際の問題に焦点を当て、技術的な変化と文化的な変化のバランスを取り、影響を測定すること—ですが、それをどのように適用するかは、範囲や利用可能なリソースによって大きく異なります。最も効果的な組織は、すべてのレベルでの改善を組み合わせることが多いです。グローバルなイニシアティブは、チーム間で一貫したツールやプラクティスを提供します。ローカルな改善は、特定の痛点に取り組み、しばしばスケールする価値のあるパターンを明らかにします。そして、これらの範囲の間で働く人々は、異なる取り組みを結びつけて一貫した戦略にまとめ、限られたリソースを強力な関係や新たに生まれるパターンを通じて利点に変えます。例えば、3つの異なるチームがそれぞれ独自の方法で遅いデプロイメントの問題を解決していることを発見するかもしれません—1つはキャッシュを改善し、別の1つはビルドを並列化し、3つ目は承認プロセスを簡素化しています。アライアンスを築き、非公式なネットワークを作りましょう。中規模の範囲では、成功はしばしば関係を築き、非公式な影響力ネットワークを作ることに依存し、正式な権限に頼ることは少ないです。ある例では、#buildimprovementsというSlackチャンネルが3人のフラストレーションを抱えた開発者から始まり、40人がヒントを共有する場に成長し、いくつかの解決策は公式に助けを求めたことのないチームにも広がりました。+ 影響力のあるチームや個人と提携し、メッセージを広める手助けをしてもらいましょう。+ 同じような課題に直面している他のチームや、すでにDevExの改善に興味を持っているチームを見つけて自然な味方を作りましょう。+ 共有の問題に基づいて非公式な作業グループや実践コミュニティを作りましょう。- 新しい正式なプロセスを作るのではなく、既存の関係や会議を活用しましょう。複数のグループに価値を提供することに焦点を当てましょう。中規模の範囲では、いくつかのグループに価値を提供することが重要です。以下の点も考慮してください： + 複数のチームが経験している問題を解決するイニシアティブを選びましょう。- 異なる文脈で共鳴する結果を共有しましょう—他のチームが自分たちの状況に関連付けられるメトリクスやストーリーを強調します。- チームが簡単に採用できる再利用可能な資産（ツール、プロセス、文書）を作成しましょう。- 他のチームが修正したバージョンを試すことができるように、アプローチを文書化しましょう。組織のダイナミクスを戦略的にナビゲートすることが成功の鍵となることがあります。ある例では、リーダーが会社がセキュリティコンプライアンスに焦点を当てていることを認識し、より頻繁な検証を通じて「セキュリティリスクを軽減する」として、迅速な自動テストを位置づけました。以下の追加戦略も考慮してください： 既存の承認プロセスや予算サイクルの中で作業し、それらを変更しようとするのではなく、活用しましょう。 フレームの改善を、現在の組織の優先事項に沿った形で行いましょう。導入のタイムラインには忍耐を持ちましょう。中規模の範囲は、しばしば遅くても持続可能な変化を意味します。また、リーダーシップにエスカレーションすべき時と、ピア・ツー・ピアで取り組むべき時を見極めることも重要です。Ibottaの「スタートアップ内のスタートアップ」として、中間からDevExチームを構築することについてです。 Minh PhamとTitus StoneがIbottaで開発者体験の改善を探求し始めたとき、彼らには正式なチームや専用の予算はありませんでした。ただ、230人のエンジニアを抱える組織にはより良い開発者ツールとプロセスが必要だという確信がありました。「私たちはこれをスタートアップ内のスタートアップと見なしています」とMinhは説明します。「組織にとって大きな価値があると信じていますが、私たちの顧客、特にリーダーシップや投資家が常に賛同してくれるとは思っていません。」 彼らの中規模アプローチは、地域の戦術と組織の影響力を組み合わせました： - 連携の構築。彼らはエンジニアに2週間の自由時間で何に取り組みたいかを尋ねる調査から始めました。圧倒的にDevEx関連の回答が寄せられ、需要の具体的な証拠を得ることができました。価値を段階的に証明すること。内部検索ツールなどの初期プロジェクトは、技術的な成功をリーダーシップが関心を持つビジネスメトリクスに結びつける方法を学ぶ手助けとなりました。継続的な関係管理。「私たちは常にエレベーターピッチやボードスライドを更新しています」とMinhは述べます。エンジニアリングリーダーシップとの月次チェックインは、彼らの整合性を保ちながら信頼性を築くのに役立ちました。この忍耐強く関係重視のアプローチは、最終的に正式なチームの地位とリソースを得ることにつながり、限られた権限という制約を、実績と強固なステークホルダー関係を通じて利点に変えました。 どんな範囲であっても、成功は実際の問題に焦点を当て、思慮深く変化を推進することから生まれます。組織全体の改善を進める場合でも、チームの日常業務を改善する場合でも、重要なのは、実際に変化を実施する能力に応じたアプローチを取ることです。そして時には、小さく始めて成功がより広い影響を生む機会を創出することが必要です。開発者体験を改善するための変更を実施する際には、進捗を追跡し、自分の仕事の価値を示すことが不可欠です。影響の明確な証拠がなければ、成功した取り組きであっても勢いと支持を失う可能性があります。次の章では、DevExの改善を評価し、そのビジネス価値を効果的に伝える方法を探ります。 ステップ7：進捗を評価し、価値を示す あなたのDevEx改善の取り組みは現在進行中で、役割と組織に適した規模で変更が実施されています。しかし、それがうまくいっているかどうかはどうやって判断するのでしょうか？また、ステークホルダーにこれらの改善の価値を理解してもらうためにはどうすればよいのでしょうか？この章では、進捗を評価し、DevExの成功をビジネスリーダーに響く言葉に翻訳する方法を示します。 評価はあなたのDevEx（開発者体験）旅の最終ステップではなく、継続的改善サイクルの重要なチェックポイントです。定期的な評価を行うことで、進捗を確認し、結果を共有し、アプローチや優先順位、指標に必要な調整を行うことができます。また、ステークホルダーの優先事項と再調整し、影響、価値、ROI（投資対効果）を効果的に伝える機会にもなります。 ### 第34章 データを分析する 世界中のデータは、分析しなければあまり価値を提供しません。あなたがDevEx改善作業を始めたとき、アクセス可能で、開発者体験のさまざまな側面を捉え、ステークホルダーに響く指標を特定しました（ステップ3）。定期的なチェックポイントに達したら、これらの指標を見直す時です。これは影響を示すためと、測定戦略を再評価するためのものです。DevEx指標に適した分析手法を選びましょう。異なる指標には、それぞれ異なる分析技術が必要であり、その真のストーリーを明らかにします。無駄な「釣り」をしないように、まず仮説を書き出しましょう。興味深いものを見つけるまでデータを切り刻むだけでは、ただの釣りです。探索的分析は価値がありますが、明確な質問なしにデータを掘り下げると、偶然の相関関係を見つける可能性が高まります。期待する結果とその理由についてテスト可能なアイデアから始めましょう。これにより、分析が正直で防御可能なものになります。 平均値の使用については慎重に考えましょう。通常分布しているデータ（ヒストグラムでプロットしたときに中央が高く、端が小さい分布）でない限り、平均値の使用は避けるべきです。計算は簡単ですが、平均値は重要な変動を隠す可能性があり、DevExデータはしばしば大きな外れ値の影響を受けます。たとえば、平均ビルド時間が4時間であっても、一部のチームは20時間かかる一方で、ほとんどの開発者は2分でビルドを完了することがあります。 集計結果をパーセンタイル（p50、p90、p99）で報告しましょう。これにより、組織全体の体験の分布が明らかになりますが、十分なデータがある場合にのみ使用してください： - **p50（中央値）**: 一般的な開発者体験を示します。 - **p90**: ほとんどの開発者体験がどのようなものかを強調します。たとえば、p90のビルド時間が8分であれば、90％のビルドが8分未満で完了し、10％はそれ以上かかることを意味します。 - **p99**: 最悪のシナリオを明らかにします。 コホート分析を活用して、より深い洞察を得ましょう。データを意味のあるセグメント（チーム、経験レベル、製品エリア、ツール使用）でグループ化し、改善が不均一な場所や特定の課題が持続している場所を特定します。時系列の可視化を使用して、時間の経過に伴うトレンドや違いを確認しましょう。指標を時間軸にプロットして、縦のトレンド、季節的パターン、特定のイベント（リリース、インフラ変更）との相関関係を特定します。既知のイベントで時系列を注釈し、その文脈でトレンドを解釈しましょう。 DevExの指標は、年の時期によって大きく影響を受けることがあります。休日や大規模なリリース、オンボーディングサイクルなどは、データを見たときに誤解を招くようなトレンドや急増を生むことがあります。相関分析を用いて、指標間の関係を調べてみましょう。例えば、ビルド時間が短いことはデプロイ頻度の高さと相関していますか？より良いドキュメントを持つチームは、オンボーディングの問題が少ないのでしょうか？AIアシスタントを使用しているチームは、コードの速度が向上していますか？AI生成のコードは、レビュー時間やバグ率とどのように相関していますか？そして、覚えておいてください：相関は因果関係を意味しません。関係の方向性を証明するには、より高度な手法が必要です。 - ただのパターンではなく、もっと妥当な説明を探しましょう。相関が存在する理由について合理的なストーリーを語れないのであれば、その相関はあまり役に立ちません。自分の専門知識を活用し、開発者と話し合って、そのパターンが意味を持つかどうかを確認してください。 + 分散と標準偏差を使って一貫性を測りましょう。使用統計の高い分散は、不均一な実装や採用を示唆し、チームが既存のデータを予測に活用するのを難しくします。ビルド時間のようなシステムの挙動における高い分散は、最適化のギャップ（キャッシングなど）を示す可能性があり、スプリントの計画や納期の見積もりを困難にします。ヒストグラムは、これを示すための有用な可視化手段です。前後比較は変化を伝えることができます。絶対的な変化（例：3分短縮）とパーセンテージの改善（例：30％の削減）を計算して、文脈を提供しましょう。 - 再訪し、洗練させましょう。仮説は進化します。あなたの発見を使って次の質問や分析を鋭くし、各サイクルで学んだことを記録し続けましょう。 マイクロソフトがコホート分析を使ってターゲットを絞った改善を推進する方法。マイクロソフトのシニアプリンシパル応用科学者であるブライアン・ハウクは、コホート分析が集約データの中に隠れているパターンを明らかにする重要なツールであることを発見しました。彼の発見は、表面的な指標を超えて見ることがなぜ重要かを示しています： リポジトリのサイズは重要です。最大のモノレポにいる開発者は、小さなリポジトリにいる開発者の2倍以上のプルリクエスト時間を経験します。この洞察は、すべてのリポジトリを一緒に分析すると消えてしまいます。予期しない言語パターンは、より深い調査を促します。ブライアンのデータセットにおけるC++開発者は、C#開発者よりも65％遅いPR完了時間を示しました。この逆説的な発見は、新たな疑問を生じさせたため、価値がありました：遅いビルドツールが原因だったのか、それとも彼らのC++プロジェクトの本質的な複雑さを反映していたのか？季節的な影響は、目の前に隠れています。データセット全体でのアクティブなコーディング時間における20％の不明な変動は、予期しない原因に遡ります：夏時間の移行が開発者の生産性に一貫して影響を与えていました。年次平均や最近の四半期データだけを見ていたら、この繰り返しのパターンは完全に見えなくなっていたでしょう。 これらの発見は、Microsoftのツール投資に直接影響を与え、チームが本当の問題と通常の作業の変動を区別する手助けをしました。分析の単位を明確に定義することを忘れないでください。DevExの指標を計算する際には、何を測定しているのかを明確にすることが重要です。「90%の開発者がビルド時間を8分未満で経験した」という表現は、「90%のすべてのビルドが8分未満で完了した」という表現とは全く異なる意味を持ちます。 この原則は、平均、パーセンタイル、コホート、相関関係を見ている場合にも当てはまります。常に、測定対象が個人、イベント、チーム、またはコードベースのどれであるかを明確にしてください。この明確さは、誤解を招く結論を避け、利害関係者がデータを正しく解釈するのに役立ちます。指標の分析を更新しましょう。指標計画に戻り、開発者の調査や前回の報告以降に収集したシステムデータを分析することで、新しいデータを集めます。現在のパフォーマンスを以下の2つの重要な基準と比較します： - イニシアティブを開始したときの初期基準 - 前回の報告期間のパフォーマンス これらの比較は、開発者体験の改善や後退を特定し、その変化のビジネス価値を計算するのに役立ちます。データのパターンを探りましょう。特定のチームが他のチームよりも改善を示しているのでしょうか？ある指標が予想以上に早く進展している一方で、他の指標は遅れているのでしょうか？これらの洞察は、次のステップを導く手助けになります。 ビルド時間やデプロイ頻度などのシステム指標を分析する際には、中心傾向（典型的な値）と分布（経験のばらつき）の両方を考慮してください。例えば、p90のビルド時間を15分から8分に短縮することは、平均を5分から4分に改善するよりも影響が大きいかもしれません。これは、生産性や満足度に不均衡に影響を与える最悪の体験に対処するからです。 AI開発ツールを使用しているチームと従来のアプローチを使用しているチームの違いにも特に注意を払いましょう。これにより、初期の導入では見えなかったAI採用の利点や潜在的な摩擦点が明らかになることがあります。調査データについては、全体のスコアと回答の分布の両方に注意を払ってください。平坦な平均スコアは、一部の開発者が喜んでいる一方で、他の開発者が不満を抱いているという意見の対立を隠しているかもしれません。分析をセグメント化してこれらのパターンを明らかにし、改善をより効果的にターゲットにしましょう。 開発者の作業に関するケーススタディを集めましょう。数字は物語の一部しか語りません。完全な状況を把握するためには、開発者の日常的な体験に関する定性的なフィードバックを収集することが重要です。以下のような質問に焦点を当ててください： - どの作業の側面が改善されましたか？ - どのプロセスが依然として困難またはフラストレーションを引き起こしていますか？ - AIツールは彼らの開発ワークフローや生産性にどのように影響していますか？ - コミュニケーションパターンは変化しましたか？ドキュメントをより多く使用するようになったり、チーム間のコラボレーションが異なったりしていますか？ 組織全体のチャンピオンたちは、彼らが集めた貴重な洞察を提供してくれるかもしれませんし、新しいイニシアティブを試しているチームに直接連絡を取ることもできます。 最も説得力のあるレポートは、定量的な指標と実際の開発者のストーリーを組み合わせて、進捗の包括的な物語を作り出します。 ### 第35章 結果を伝える準備をする 異なるオーディエンスは、開発者体験の異なる側面に関心を持っています。データを共有する際には、ステークホルダーを意識しましょう。主なステークホルダーグループは開発者とリーダーシップであり、ここではその例をいくつか紹介します。 #### 開発者向けのアプローチ： - **日常業務に影響を与える改善に焦点を当てる。** - **時間の節約。** 改善されたプロセスやフィードバックループが日常業務にどのように影響するかを示します。 - **手間の軽減。** 自動化やツールの改善がどのように煩わしい手作業を排除したかを定量化します。 - **集中時間の向上。** 会議やカレンダーの運用方法の変更が、深い作業のための中断のない時間をどのように生み出したかを示します。 これらの計算を開発者に提示する際には、指標を彼らの体験に直接結びつけましょう。「ビルド時間が30%改善された」と報告するのではなく、「30%早いビルドは、フローを維持し、変更に対するフィードバックを迅速に得られることを意味し、平均で1日あたり45分を節約できる」と翻訳します。 #### リーダーシップ向けのアプローチ： リーダーシップは、DevExの変化とそれがビジネスに与える影響に関心を持っています。第III部「ビジネスケースを作る」では、DevExの取り組みを彼らが関心を持つビジネスに影響を与えるものと結びつける5つの方法を特定しています。ここでも同様のアプローチを使って進捗を伝え、彼らに響く要素を活用し続けます。 改善をビジネス価値に結びつけることは、旅の段階によって異なります。たとえば、生産性の向上を共有することは最初の数ヶ月で可能かもしれませんが、収益に結びつけるには製品開発サイクルのためにもっと時間がかかることがあります。この点については第III部で詳しく説明しますが、ここで簡単に繰り返します： - **収益を上げる：** 収益の加速。DevExの改善とビジネス価値の関係を示します。機能の市場投入までの時間を短縮し、デプロイメントの改善を特定の製品リリースとそのビジネスへの影響に結びつけることができます。 - **コストを削減する：** 直接的なコスト削減を定量化します。効率的なビルドによるクラウド支出の削減、標準化によるライセンスコストの減少、インフラコストの低下を計算します。これらの節約は直接的に利益に影響を与え、継続的なコストについては、これらの節約が時間とともにどのように積み重なるかを示します。 - **時間の回復と生産性の向上。** フリクションを減らすことで節約できた時間を計算します。特に、開発者がタスクを切り替えるのではなく待機するプロセスにおいてです。これらの節約を開発者全体に掛け算し、完全なエンジニアリングコストを用いてドル価値に変換します。 - **ビジネス成果との相関。** DevExの改善をビジネスメトリクスに結びつけます。ビルドパフォーマンスの向上が生産インシデントの減少とどのように相関するかを示し、そのインシデントの減少を基準となる平均コストで掛け算します。 - **リーダーを悩ませる問題の解決。** DevExの改善とリーダーの優先事項との明確な関連を示します。 例えば、文書はセキュリティの強化やコンプライアンスの向上に寄与します。これらの関連性は明白かもしれませんが、リーダーシップに対しては明確に説明する必要があります。また、会社の優先事項に結びつけて、DevExが現在の会社の取り組みをどのように支えているかを示しましょう。もし組織がセキュリティ強化に取り組んでいるなら、増加した自動化がどのようにしてすべてのコミットにセキュリティチェックを組み込むかを示し、同時に開発者の体験（手作業の軽減）とセキュリティの強化（一貫した施行）を改善することをアピールしましょう。これは誇るべき成果です。リーダーに対して、四半期ごとのレビューや取締役会のプレゼンテーション、業界の会話で強調できる具体的なDevExの成功事例を提供しましょう。例えば、「私たちのチームはビルド時間を40%短縮し、業界のトップパフォーマーの一員となりました」や「デプロイメントプロセスの85%を自動化し、追加の人員なしで週末にリリースできるようになりました」といった具体的な成果です。これらの成果は、リーダーにとって自らのリーダーシップを反映しつつ、DevExへの投資の価値を示す具体的な成功事例となります。 パフォーマンスのギャップを示し、改善がどのように会社を業界標準に近づけているかを説明しましょう。現在の状態と可能な状態とのギャップを埋めることを強調します。これらの計算をリーダーに提示する際には、ビジネスゴールや言語に結びつけて説明します。「ビルド時間が30%改善されました」と単に報告するのではなく、「エンジニアは毎日45分を節約し、年間9,750時間のエンジニアリング時間を取り戻し、1.2百万ドルの価値を生み出しています」と翻訳します。最大のインパクトを得るためには、リーダーシップの優先事項に沿った焦点を絞った分析をパッケージ化しましょう。例えば、ROIを示すためにシンプルな表を使用できます： | DevExイニシアティブ | 年間価値 | 価値タイプ | 実施コスト | |------------------|---------|-----------|-----------| | ビルド加速回収 | $3.3M | 生産性 | $420K | 79x | | CI/CD最適化削減 | $1.2M | 直接コスト | $380K | 3.2x | | 品質自動化回避 | $1.92M | インシデントコスト | $550K | 24x | | **合計インパクト** | **$5.8M** | **$1.35M** | **43x** | 異なるリーダーシップの聴衆に合わせてプレゼンテーションをカスタマイズすることを忘れないでください。CFOはハードコストの削減やROIに関心を持つ一方、CTOは財務的な利益とともにエンジニアリング文化の改善に焦点を当てるかもしれません。DevExへの継続的な投資のための強力なビジネスケースを作成する方法については、Part IIIを参照してください。詳細な計算例、実用的なテンプレート、聴衆特有のコミュニケーションガイドについては、Step 7 Workbookをご覧ください。 手動から自動評価への進化。DevExイニシアティブが成熟するにつれて、手動分析からより自動化された評価システムへと自然に進化します。この進化は、製品開発と同様の予測可能なパターンに従います。初期段階では、手動プロセスから始め、データを手動で引き出し、分析を行い、レポートを作成し、ダッシュボードを更新することを期待してください。このハンズオンアプローチには利点があります。メトリクスに対する深い理解を築き、ステークホルダーにとって実際に重要なデータポイントを特定するのに役立ちます。 自動化の前に価値に焦点を当てる。スタートアップがプロダクトマーケットフィットを見つけるように、自動化に多額の投資をする前に、価値のある洞察を提供することを優先しましょう。 これらの初期サイクルを利用して、ステークホルダーからのフィードバックに基づいて、メトリクス、ビジュアライゼーション手法、報告フォーマットを洗練させていきましょう。 - 高価値なコンポーネントを段階的に自動化します。どのメトリクスやレポートが一貫して価値を提供するかを確立したら、それらの収集と提示を自動化し始めます。最も時間がかかる、または頻繁に必要とされる要素から始めましょう： + よく使われるシステムメトリクスのデータ収集スクリプト。 - 標準化されたビジュアライゼーションを用いた再利用可能なレポートテンプレート。 + 重要なダッシュボードのための定期的なデータ更新。 - ステークホルダーへの定期的な更新の自動配信。 - 包括的な測定プラットフォームを開発します。DevEx改善プログラムがより確立されるにつれて、データソースを統合し、分析を自動化し、異なるステークホルダーグループにメトリクスへのセルフサービスアクセスを提供する、より堅牢なプラットフォームの構築に投資しましょう。成熟したDevExプログラムでも、特に定性的な評価やストーリーテリングに関しては、いくつかの手動コンポーネントが維持されることを忘れないでください。目標はすべてを自動化することではなく、ルーチンのデータ作業から時間を解放し、洞察の生成や戦略的改善に集中できるようにすることです。 ビジュアライゼーションを使用して可読性を向上させ、インパクトを最大化しましょう。効果的なデータビジュアライゼーションは、生の数字をステークホルダーがすぐに理解できる魅力的なストーリーに変換します。よくデザインされたビジュアルは、発見をよりアクセスしやすくするだけでなく、表やテキストだけでは見逃されがちな重要な改善点やパターンを強調するのにも役立ちます。特に忙しい経営者やマネージャーは、テキストよりも視覚情報を迅速に処理します。考え抜かれたチャートや図は、説明に数段落かかる内容を数秒で伝えることができます。DevExイニシアティブでは、異なるチームやシステム間で複数のメトリクスを追跡することが多いため、強力なビジュアライゼーションが進捗を示し、ステークホルダーの関与を維持するために不可欠です。効果的なDevExビジュアライゼーションの鍵は、特定のデータとオーディエンスに適したフォーマットを選択し、それを明確かつ目的を持って実行することです。あなたのビジュアルは、ステークホルダーの最も重要な質問に即座に答えるべきです。「私たちは改善していますか？」 「次はどこに焦点を当てるべきですか？」 「このイニシアティブは価値を提供していますか？」これらのビジュアライゼーションフォーマットは、DevEx報告に特に効果的です： - 削除されたステップや簡略化されたプロセスを示す並列ワークフローダイアグラム。これは、開発者のワークフローの複雑さが減少したことを示すのに特に効果的です。明確な注釈を付けて、何が削除または改善されたかを指摘し、一貫した色と形を使用しましょう。 - 主要なメトリクスを強調するビフォー/アフターのチャート。バーまたはカラムチャートがこの目的に適しており、公平な比較を確保するために一貫したスケーリングを使用します。改善を強調するために色を使用することを検討してください。 - 一目で方向性と影響を解釈しやすくする注釈付きメトリクス比較。上昇/下降の矢印や色分け（改善には緑、悪化には赤）などの視覚的な手がかりを含めましょう。 回帰分析や、変更がポジティブかネガティブかを示すシンプルなアイコンを使用します。例えば、ビルド時間の減少を緑の下向き矢印で示し、デプロイ頻度の増加を緑の上向き矢印で示します。また、時間の経過に伴う指標のパフォーマンスを示すスパークラインやトレンドラインも有効です。これらのコンパクトなビジュアライゼーションは、イニシアティブが成熟し、報告期間が増えるにつれて特に価値が高まります。単純なビフォー・アフターの比較を超えたコンテキストを提供します。最大のインパクトを得るためにレイアウト戦略を活用しましょう。効果的な個別のビジュアライゼーションを作成することは出発点に過ぎません。これらのビジュアルをレポートやダッシュボードに配置する方法は、その影響力や有用性に大きく影響します。考え抜かれたレイアウトは、ステークホルダーをデータストーリーに導き、最も重要な点に焦点を当てさせます。DevExレポートを設計する際には、以下のレイアウト原則を考慮してください。 1. 視覚的な階層を確立し、最も重要な発見に視聴者の注意を引きつけます。主要な指標や最も重要な改善点は、レポートの上部や冒頭に目立つように配置します。 2. 内在する緊張感のある指標を表示し、ユーザーがトレードオフを簡単に理解できるようにします。 3. 一貫したダッシュボードレイアウトを作成し、類似の指標をグループ化し、報告期間全体で一貫した配置を保ちます。この親しみやすさは、ステークホルダーが関心のある情報を迅速に見つけるのに役立ちます。 4. プログレッシブディスクロージャーを実施し、高レベルの要約から始め、詳細なデータに掘り下げる方法を提供します。エグゼクティブサマリーでは集計された改善点を示し、リンクされたセクションや展開可能な要素は、必要なチーム固有のデータを明らかにします。 5. テキストとビジュアルのバランスを取り、異なる学習スタイルをサポートします。重要な洞察は、ビジュアルとテキストの両方で強調され、テキストはビジュアルの背後にある「それが何を意味するのか」を説明します。 6. ホワイトスペースを効果的に使用して異なるセクションを分け、視覚的な過負荷を防ぎます。密度が高く、混雑したレポートは、ステークホルダーが最も重要な点を特定するのを難しくします。 7. 異なるステークホルダーグループ向けにターゲットを絞ったビューを作成し、彼らの優先事項に最も関連する指標を強調します。エグゼクティブが見るべき情報は、エンジニアリングマネージャーが見るべき情報とは異なります。 8. ビジュアライゼーションを作成する際には、データを表示することだけが目的ではなく、ステークホルダーの重要な質問に数秒で答えることが目標であることを忘れないでください。「私たちは改善していますか？」、「どの領域にもっと注意が必要ですか？」、「開発者は作業においてどのようなトレードオフを強いられていますか？」などです。 明確さとインパクトのための確立されたベストプラクティスに従いましょう。DevExの改善を魅力的かつ正確に表現するためのビジュアライゼーションガイドをステップ7のワークブックに含めています。分析と報告の反復的な性質についても触れておきます。データ駆動型のDevExレポートを準備することは、ほとんど直線的なプロセスではありません。分析とコミュニケーションの間を複数回行き来することがよくあります。以下のステップを参考にしてください。 1. 指標計画に基づいて初期データを分析します。 2. 報告書やプレゼンテーションの草案を作成し始めましょう。3. 初期の調査結果から生じるギャップや新たな質問を発見します。4. 追加の分析や異なる視覚化手法のためにデータに戻ります。5. これらの新しい洞察を報告書に組み込みます。6. 同僚にメッセージの明確さをテストしてもらいます。7. フィードバックに基づいて視覚化や説明を洗練させます。この循環的なプロセスは通常のことであり、価値があります。各回の繰り返しは、データの理解を深め、その重要性を効果的に伝える能力を向上させます。特にリーダーシップへの重要なプレゼンテーションのために、報告スケジュールにこれらの繰り返しの時間を確保しましょう。 第36章 進捗を共有する DevEx改善イニシアティブで進捗を上げるだけでは不十分で、その進捗をステークホルダーに伝える必要があります。コミュニケーションのタイミングを戦略的に考えましょう。異なるステークホルダーは異なる頻度での更新を必要とします。一般的には以下の頻度を推奨しますが、あなたの状況に応じて異なるものがより効果的かもしれません。重要なのは、既存の会議やビジネスのリズムに合わせることで、既存の構造やプロセスを活用できるようにすることです。 - 経営層：年に2回、ROI、戦略的整合性、1～2の際立った技術例に焦点を当てます。 - 技術リーダーシップ：四半期ごとのビジネスレビューで、技術の改善や組織への影響・価値、適切な比較（例：前回の報告や類似の他組織との比較）に焦点を当てます。 - エンジニアリングマネージャー：月次の更新で、チーム特有の利点を強調します。また、エンジニアリングマネージャー向けの利用可能なツールやリソースについての定期的なリマインダーも考慮することをお勧めします。 - 開発者：月次の更新で、開発者としての彼らに利益をもたらす改善を強調し、詳細なデータやダッシュボードへのアクセスを提供して、さらに学んだり深掘りしたりできるようにします。また、彼らの作業を改善するための利用可能なツールやリソースについての定期的なリマインダーも考慮することをお勧めします。 重要な発表のタイミングも重要です。重要な結果を共有する際には、大規模な製品の発表、組織の発表、祝日と競合しないようにしましょう。 DevEx評価を組織のリズムに統合する 最大の影響を与えるために、DevEx評価プロセスを組織の確立されたビジネスリズムに合わせましょう。この統合により、DevExの洞察が重要な意思決定が行われる際に利用可能になり、別の会議やプロセスを必要とせずに影響を与える自然な機会が生まれます。 - 四半期ごとの計画サイクル：四半期の計画が始まる2～3週間前に包括的なDevEx評価をスケジュールします。このタイミングにより、チームが優先事項を決定し、リソースを配分する際に新しい洞察を提示できます。DevExの改善が主要なビジネス目標をどのようにサポートしているか、さらなる投資がどこで最大のリターンをもたらすかを強調する要約を準備しましょう。 - 年次予算プロセス：予算計画が近づくにつれて、前年対前年のDevExデータをまとめます。 ROIやビジネスインパクトを示す指標に焦点を当てましょう。過去の投資がどのように成果を上げたかを明らかにし、提案された取り組みから得られる潜在的なリターンを示す予測を作成します。直接的なコスト削減や生産性向上を、財務チームが容易にモデルに組み込める金銭的な観点で定量化します。 パフォーマンスレビューサイクルでは、エンジニアリングマネージャーにチーム固有のDevExデータをパフォーマンスレビュー期間の前に提供します。この情報は、DevExの改善に貢献したチームメンバーを認識し、チームが追加のサポートやトレーニングを必要とする領域を特定するのに役立ちます。個々の貢献者にとって、DevExイニシアチブへの参加を文書化することは、機能の提供を超えた具体的な影響の例として役立ちます。 技術ロードマップのレビューでは、技術リーダーシップが技術ロードマップをレビューする際に、DevExの考慮が反映されるようにします。開発者体験の摩擦点が計画された技術的変更とどのように一致するかを示すデータを提示します。これにより、既に計画されている作業の一環としてDevExの課題に対処する機会を強調できます。 オンボーディングおよびトレーニングプログラムでは、エンジニアのオンボーディングやトレーニングを担当するチームとターゲットを絞ったDevExの洞察を共有します。これにより、新しいチームメンバーが開発環境の最も困難な側面を乗り越えるためのスキルと知識を身につけることに集中できます。 DevEx評価を既存の組織プロセスに統合することで、DevExを別のイニシアチブから組織の運営における埋め込まれた考慮事項に変えることができます。このアプローチは、DevExが注意を引くために競争しているという認識を減少させ、既存の作業を見直し、強化するためのレンズとして位置づけます。 データとストーリーテリングのバランスを取ります。指標は信頼性を提供しますが、ストーリーは理解と感情的なつながりを生み出します。各主要な改善について： - ビフォー・アフターの体験を示す代表的なユーザージャーニーを特定します。 - 数字を生き生きとさせる具体的な開発者の証言を集めます。 - 特に恩恵を受けたチームの簡潔なケーススタディを作成します。 - 非技術的なステークホルダーが技術的な改善を理解できるようなアナロジーを使用します。 例えば、「PRレビュー時間が40％減少した」という声明に対して、「モバイルチームは以前、コードレビューに平均2日待っていたため、開発者は複数のタスクの間でコンテキストスイッチを強いられていました。今では、数時間以内にコードレビューの返答を受け取ることができ、集中力を維持し、スプリントの範囲内で一貫して機能を出荷できるようになりました。」というストーリーを組み合わせます。 開発者の調査やチームとの継続的な議論は、聴衆に響く例を得るための素晴らしい情報源です。（プロのヒント：パイロットや実験チームと密接に連絡を取り合うことは、これらのストーリーや洞察を得るための良い方法です。） 帰属の課題：複雑な世界におけるDevExの測定。DevExの改善を実施する際、組織内の他の多くの要因が影響を及ぼす可能性があります。 同時に変化している要素には、新しい技術の導入、組織の再編成、スタッフの変更、その他のプロセス改善などが含まれます。このため、「私たちのDevExイニシアチブXが改善Yを引き起こした」と明確に言うことは難しく、複数の要因が絡んでいるからです。帰属の課題に対しては、以下のように透明性を持って対処しましょう。 - 複数の要因を認める。メトリクスに影響を与える可能性のある他の組織の変化を特定し、議論します。 - ターゲットを絞った比較を実施する。可能であれば、新しいプロセスを使用しているチームと従来の方法を守っているチームとのコントロールグループを使用します。 - 特定のフィードバックを収集する。開発者に対して、あなたのイニシアチブがどのように彼らの仕事に直接影響を与えたかについて具体的な質問をします。「新しいCIパイプラインは、あなたのデプロイメントの自信にどのように影響しましたか？」 - 相関関係を慎重に提示する。改善を示すデータを共有しつつ、限界について正直に言及します。「Xを実施した後、Yの改善が見られました。この改善を私たちのイニシアチブだけに帰属させることはできませんが、開発者のフィードバックは強い関連性を示唆しています。」 利害関係者は、測定の限界についての正直さを評価します。変化の帰属に関する課題について透明性を持つことは、あなたのDevExアプローチの成熟を示し、結果の信頼性を高めます。 ### 第37章 矛盾するメトリクスを乗り越える 複雑なシステムにおいて矛盾する信号は通常のことであり、慎重にアプローチすることで貴重な洞察を提供します。DevExデータを分析する際、異なるメトリクスが互いに矛盾しているように見える状況に直面することがあるでしょう。注意すべき一般的な矛盾パターンには以下があります。 - スピードと品質の緊張。ビルド時間が短縮され、コミット頻度が増加する一方で、テストの失敗が増えたり、コードレビューの徹底度が低下したりする。 - 開発者満足度の不一致。開発者の満足度が向上する一方で、出力メトリクスが減少する。 - 導入と生産性の逆説。ツールの導入率が高いが、生産性の向上は最小限である。 - 短期的と長期的なトレードオフ。インフラ改善後に即座に生産性が低下し、長期的な利益が約束される。 - AI導入の逆説。AIツールの使用が高いが、生産性の向上が不明確であったり、コード生成速度が向上する一方でレビューサイクルが長くなる。 これらの矛盾に直面したときは、ポジティブなストーリーを語るメトリクスだけに焦点を当てる誘惑に抵抗しましょう。代わりに： - メトリクス間の関係を調査する。関連性のあるメトリクスを互いにプロットして、パターンや相関関係を特定します。コード提出の増加がPRの品質低下を引き起こしているのか、それとも無関係なのか？ - 分析をセグメント化する。矛盾するメトリクスをチーム、製品エリア、または開発者の経験レベルごとに分解します。しばしば、矛盾は異なるセグメントに異なる影響を与えることが明らかになると解消されます。 - 時間の視点を考慮する。ある改善は一つのメトリクスで即座に利益を示す一方で、他の改善は現れるまでに時間がかかることがあります。 メトリクスを長期間にわたって追跡し、遅延効果を特定し、初期のトレードオフが最終的にバランスを取るかどうかを判断します。また、デプロイメントのフリーズ期間、休日、季節の変化の影響も考慮してください。開発者を解釈に巻き込みましょう。メトリクスが対立する場合は、これらの変化を経験している開発者とデータについて議論します。彼らの文脈的理解は、メトリクスが逆方向に動く理由を明らかにすることがよくあります。ステークホルダーに対して全体像を提示しましょう。報告する際には、メトリクス間の緊張関係を認め、それが何によって引き起こされているのかを分析して示します。この微妙なアプローチは信頼性を高め、より情報に基づいた意思決定につながります。たとえば、新しいCI/CDパイプラインがビルド時間を短縮した一方でテストカバレッジを減少させた場合、調査を通じて開発者がワークフローを迅速化するために特定のテストスイートをバイパスしていることがわかるかもしれません。この洞察は、より効率的なテスト戦略の必要性を示唆しており、ビルドの迅速化に根本的な問題があるわけではありません。テストスイートをスピード向上のためにリファクタリングしたり、ターゲットを絞ったテストを実施することで、品質を維持しつつビルド時間の改善を保つことができるかもしれません。メトリクスの対立を慎重に分析することで、潜在的な混乱を開発エコシステムや開発者体験のさまざまな側面間の複雑な相互作用についての深い洞察に変えることができます。 第38章 学び、改善する あなたの目標は、うまくいったことやうまくいかなかったことから学び、組織内の開発者体験（DeveEx）を継続的に改善することです。結果のリポジトリを維持しましょう。過去のパフォーマンスと行動の記録を持つことは、学習を助ける最良の方法の一つです。ステークホルダーが時間をかけてDeveExの改善を追跡できる中央の場所（ウィキ、ダッシュボード、定期報告など）を作成します。この歴史的記録は、持続的な影響を示し、あなたの取り組みに対する継続的な投資を確保するために非常に貴重です。DeveExの改善の価値を慎重に計算し、伝えることで、技術的な成功を組織の勢いに変え、開発者体験への継続的な投資を支持します。ダッシュボードを作成する場合は、現在のパフォーマンスや時間の経過に伴うトレンドだけでなく、確立した報告のタイムフレームにおけるデータの状態も確認できるようにしてください。（例：「今日はどうなっているのか、初期のベースラインや前回の報告と比較したいが、過去4四半期のパフォーマンス状況も見たい。」）評価を実行可能な洞察に変えましょう。これらの洞察は、あなた自身のDeveExイニシアチブを導き、ステークホルダーが情報に基づいた意思決定を行うために必要な情報を提供します。特に新しいツールへの投資を評価する際に価値があります。たとえば、開発者がAIアシスタントを使用しているかどうかだけでなく、それらのツールが実際に彼らの体験や生産性を向上させているかどうかを理解することが重要です。私たちが議論したように、リーダーと開発者は異なるニーズを持っています。 高レベルの視点は、経営者が戦略的なリソース配分の決定を行い、DevEx（開発者エクスペリエンス）改善への投資がビジネスに与える影響を理解するのに役立ちます。一方で、エンジニアリングマネージャーや開発チームは、特定の摩擦点を診断し、ターゲットを絞った解決策を実施するために、より詳細なデータが必要です。 setbacks（挫折）に対しては建設的に対処しましょう。すべてのDevExの取り組みや実験が期待通りの結果をもたらすわけではありません。指標が期待外れの進捗を示す場合、あるいは後退を示す場合でも、これらの結果を軽視したり隠したりする衝動に駆られないようにしましょう。代わりに： + 不足を防御的ではなく好奇心を持って捉えましょう。 + 期待と結果のギャップに寄与した要因を分析しましょう。 - 開発者と直接対話し、何がうまくいっているのか、何がうまくいっていないのかを理解しましょう。 + これらの洞察を次の取り組みを強化するための貴重な学びとして位置づけましょう。 例えば、ビルド時間の改善が目標の30％に対して15％の削減にとどまった場合、その結果を報告するだけでなく、なぜそうなったのかを調査しましょう。初期のベースライン測定がビルドシナリオの全体的な複雑さを捉えていなかった可能性や、解決策がいくつかのボトルネックのうちの一つにしか対処していなかったかもしれません。これらの洞察は次の改善サイクルの出発点となります。 新しい開発とシステムメンテナンスのバランスを取ることが重要です。DevExおよびプラットフォームチームは、新機能や革新による問題解決にのみ焦点を当てることはできません。システムメンテナンス、時には「ライトをつけておく作業（KTLO）」と呼ばれる作業のための時間を明示的に確保する必要があります。シリコンバレー・プロダクトグループのマーティ・カガンは、従来のプロダクトチームはメンテナンスに最大30％の時間を必要とし、プラットフォームチームは最大50％を必要とすることがあると見積もっています。この高い負担は、プラットフォームシステムの重要性と複雑さを反映しています。ビルドシステムやデプロイメントパイプラインが壊れると、組織内のすべての開発者に影響を及ぼします。メンテナンス作業には、依存関係の更新、パフォーマンスの監視、インシデントの処理、古いコードのリファクタリング、システムのスケーリング、ドキュメントの更新が含まれます。この作業は、何かが壊れるまでステークホルダーには見えにくいという課題があります。新機能が興奮を生むのに対し、メンテナンスは現状を維持する役割を果たします。 メンテナンスの配分を明示化しましょう。「時間があるときに行う作業」としてメンテナンスを扱うのではなく、チームのリソースの40～50％を最初からメンテナンスや運用作業に確保しましょう。残りのキャパシティを新しい取り組みに使用します。ステークホルダーとのコミュニケーションでは、メンテナンスを技術的負債や信頼性リスクに対する保険として位置づけましょう。反応的なメンテナンスのコストは、ほとんど常にプロアクティブなメンテナンスよりも高くなります。 DevExの進捗を評価する良いタイミングです。各取り組みを評価し、改善そのものとその測定方法についてフィードバックを集めましょう。 - 指標は開発者にとって本当に重要なことを捉えていますか？ - 指標はビジネスの優先事項と一致していますか？ 重要なステークホルダーの質問に、あなたが持っているデータで答えることができますか？ - あなたが始めたときには見えなかった新たな摩擦点はありますか？ - チームのワークフローや技術が変化し、それに応じてアプローチを調整する必要がありますか？このフィードバックは、各評価が次に何を改善するかだけでなく、プロセス全体へのアプローチにも影響を与える好循環を生み出します。これらの洞察を活用して： - イニシアティブのロードマップを更新します。影響データや進化する開発者のニーズに基づいて、計画された改善の優先順位を再設定します。期待される価値を提供していないイニシアティブや、変化する要件によって上書きされたものは終了させます。 - メトリクスのフレームワークを洗練させます。測定アプローチは、理解が深まるにつれて進化するべきです。価値をよりよく捉える新しいメトリクスを追加し、既存のものを修正して精度を高め、期待したほど意味がなかったメトリクスは削除します。 - 戦略を再検討します。定期的にステップ4（優先順位と戦略の設定）に戻り、実データに基づいた新たな視点で見直します。これにより、高い影響を持つ領域に注力したり、新たに発見された痛点に対応したり、ビジネス戦略の変化に合わせてDevExの優先順位を再調整することが求められるかもしれません。 - 変更を透明に伝えます。評価データに基づいて方針を調整する際には、ステークホルダーに何を、なぜ変更するのかを共有します。これにより、あなたのDevExプログラムがデータに基づいており、応答性があることを示すことで信頼性が高まります。DevExに優れたチームは、学んだことに基づいてソリューションと測定アプローチの両方を一貫して洗練させ、時間と共により効果的な適応システムを構築します。 - 学びを体系的にします。学びを偶然に任せないでください。主要なイニシアティブを完了した後に専用の振り返りをスケジュールし、以下を文書化します： - 実施と測定の両方でうまくいったこと。 - アプローチで改善できる点。 - ステークホルダーのニーズがどのように進化したか。 - あなたの視野に入っていなかった新たなDevExの課題。 これらの洞察は、次の改善サイクルのステップ1（開発者の声を聞く）およびステップ3（データ収集）に直接フィードバックされ、DevExの取り組みが常に進化し、静的または実際のニーズから切り離されることがないようにします。効果的に行われると、この学びと適応のプロセスは、DevExを孤立したプロジェクトの連続から、開発者とビジネスの両方に一貫して価値を提供する継続的な能力へと変革します。 第39章 評価は好循環の一歩に過ぎない 効果的な評価は、現在の改善を将来のイニシアティブに結びつける架け橋です。影響を測定し、価値を伝え、学んだことに基づいて適応することで、時間と共に勢いを増す持続可能なDevEx改善のサイクルを作り出します。測定された、証明されたDevExの改善の累積的な効果は、個々のメトリクスを超えて、開発者体験が重視され、継続的に向上される文化を創造します。繰り返し成功を示すことで、DevExは次第にシフトしていきます。 コストセンターとして見なされることから、組織が価値を提供する能力を加速させる戦略的な優位性へと移行することが求められています。この評価サイクルを終えた今、あなたは新たなスタートを切る準備が整いました。より深い洞察、より良いデータ、そして強力なステークホルダーの支持を武器にして。学んだことに基づいてデータ収集戦略を洗練させるためにステップ3に戻るか、開発者の声に新たな耳で耳を傾けるためにステップ1を再訪してください。優れた開発者体験への旅は継続的なものであり、各サイクルを経るごとに、開発者とビジネスのためにより多くの価値を生み出すことができるでしょう。 ### 第5部 **DevExの進化と持続** 成功した開発者体験イニシアチブを構築することは始まりに過ぎません。本当の課題は、それを持続可能にし、時間とともにその影響を拡大することにあります。一度限りのプロジェクトとは異なり、DevExの改善には継続的な注意、進化、そして持続的な価値を提供するための組織的なコミットメントが必要です。最も成功したDevExイニシアチブには、3つの重要な特徴があります。リソースを確保し、拡張に必要な資源を保護すること、継続的な変化と採用を支える組織構造を作ること、そして長期的な持続可能性を優先するプロダクトマインドセットで技術ソリューションを構築することです。これらの基盤がなければ、どんなに技術的に優れた改善も停滞し、採用が失われたり、最終的には開発者の生産性を損なうメンテナンスの負担となってしまいます。この部分では、あなたのDevExの取り組みを有望な実験から持続的な組織能力へと変革するための実践的なフレームワークを提供します。イニシアチブに戦略的にリソースを配分し、チームが改善を受け入れるのを助ける変革管理構造を作り、持続可能な技術ソリューションを構築し、ニーズに応じて進化する指標を開発する方法を学びます。これらの実践をマスターすることで、初期の興奮が薄れた後もDevExへの投資が価値を提供し続けることを確実にします。 ### 最初の実践 **DevExイニシアチブにリソースを配分する** DevExの推進者は普遍的な真実に直面しています。必要なリソースをすべて持つことはできませんが、大きな影響を与えることは可能です。「ここではリーダーシップが理解していない。」 「ここではDevExチームが資金不足だ。」 「ビジネスはコアプロダクト以外のことに関心がない。」 業界全体で技術リーダーが開発者体験を改善するためのリソース不足を嘆く声をよく耳にします。しかし、厳しい現実があります。ほとんどの内部イニシアチブと同様に、あなたのDevExの取り組みは常に資金不足に感じられるでしょう。この本全体で説明しているように、開発者体験への投資は自然に行われることはほとんどなく、誰かが立ち上がって変革を推進する必要があります。第1部で探求するROIの計算は、単なる学術的な演習ではなく、リソースを確保するための重要な武器となります。 即座に資金を得られないからといって諦めるのではなく、成功した開発者体験（DevEx）キャンペーンのほとんどが予測可能な道のりを辿ることを認識しましょう。彼らは、借りた時間で活動する1人または2人の情熱的な支持者から始まり、早期の成功を収めることで正式な資金調達への扉を開き、最終的には専任チームや組織全体の取り組みへと成長していきます。 ### 第40章 #### 初期の取り組みを自力で進める 限られたリソースでDevEx改善イニシアチブを始める準備をしましょう。スタートアップのように。今日耳にする印象的な開発者体験の取り組みのほとんどは、1人または2人が計算されたリスクを取ることから始まりました。新しい事業を立ち上げるのと同様に、初期の開発者体験プロジェクトを成功に導くための万能のプレイブックは存在しません。しかし、努力、機転、戦略的な実行、そして少しの運を組み合わせることで、勢いをつけて成功を収めることができます。以下に、重要な初期段階へのアプローチ方法を示します。 - **汗をかく覚悟を持つ**: ショートカットはありません。最初の頃は、コアの責任の合間に時間を見つけて進展を図る必要があります。他の人に仕事を頼むだけではなく、自分自身も貢献する必要があります。 - **既存のプログラムを活用する**: もしあなたの会社が「20%の時間」（Googleで普及し、AdSenseなどの製品を生み出しました）や「Think Fridays」（IBMの今は廃止されたプログラムで、数百の特許を生み出しました）、イノベーションデー、ハッカソンなどを提供しているなら、これらの機会を戦略的に利用しましょう。これらはアイデアを発展させたり、他の人と協力したりする時間を提供し、組織内での可視性を高めることができます。 - **ボランティアの連携を築く**: DevExはほとんどの開発者や現場のマネージャーに共感されるテーマです。時間を提供したり、フィードバックをくれたり、あなたの取り組みを支持してくれる仲間を募りましょう。他の人からの小さな貢献でも、作業負担を大幅に分散させ、あなたのイニシアチブの信頼性を高めることができます。 - **問題に焦点を当て、解決策にこだわらない**: 特定のビジョンや技術的アプローチに愛着を持たないようにしましょう。特定の解決策を実施するのではなく、組織内の開発者が抱える実際の痛点を解決することに集中してください。特にAIツールが利用可能になる中で、単に新しいからという理由でAIソリューションを採用する誘惑に負けず、実際に開発者が直面している摩擦点を解決するかどうかに焦点を当てましょう。あなたが支援している開発者からのフィードバックに基づいて、方向転換する意欲を持ちましょう。 - **早期の成功を優先する**: 限られた時間とリソースの中で、目に見える価値を提供する小さな賭けに集中しましょう。ステップ2の早期の成功アプローチは、追加のリソースを確保するために必要な勢いを生み出します。各成功は次の少し大きな取り組みの信頼性を高めます。 - **学びと反復を受け入れる**: すべてのDevExプロジェクトが成功するわけではありません。各試みを、組織のニーズや制約をよりよく理解するための学びの機会と捉えましょう。 ウェイン・グレツキーが有名な言葉を残しています。「打たないシュートは100％外れる。」 DoorDashの開発者体験（DevEx）の旅は、夜や週末を利用した取り組みから、完全に資金が提供されるまでの道のりです。 現在、DoorDashで開発者の生産性を担当しているアダム・ロガルは、この道のりを体現しています。アダムの主な役割は、既存の社内開発者プラットフォームを監督することでした。しかし、彼はより良い開発者ツールとそれらのツールへのアクセス方法の必要性が高まっていることを感じていました。Uberでの経験を活かし、彼は社内開発者ツールの統一インターフェースのビジョンを持っていましたが、すぐに取り組むための資金を確保することはできないと認識しました。資金や許可を待つのではなく、彼は自ら手を動かし、夜や週末を使って、DoorDashの非常に成功した（そして完全に資金が提供された）社内開発者ポータル「DevConsole」の概念実証を構築しました。彼の旅を振り返り、アダムは「これを作りたいと思う人は、創業者でなければならない。自分の自由な時間をすべてこのようなものに投資する意欲がある人です。なぜなら、これはスタートアップの中のスタートアップだからです。」と語っています。 ### 専門の機能を構築する DevExの改善努力が軌道に乗ると、次のステップは組織内にそのための場所を確保することです。初期の取り組みが軌道に乗ると、専任の開発者体験チームを設立する機会が訪れます。これは、初期プロジェクトが明確な価値を示したり、リーダーシップが開発者の生産性に関する新たな戦略的ニーズを認識したときに起こることが一般的です。第III部「ビジネスケースの構築」のアドバイスが役立つでしょう。 ### 痛点が組織の変化を促すとき Extendの体験責任者であるマシュー・シュライペルは、彼らの専任開発者体験チームがどのように誕生したかを説明しています。「私たちのビルドとテストプロセスの完了時間は制御不能でした。この問題を解決するためには、私たちのサービスのすべてに対して所有権を持つ専任チームが必要でした。このニーズからプラットフォーム部門と開発者体験チームが生まれました。」 技術的な摩擦が複数のチームに影響を与えるほど深刻になると、それを体系的に解決するための専門的リソースへの投資を正当化しやすくなります。開発者体験チームは、組織内でさまざまな形態を取ります。時にはCTOやエンジニアリングVPに直接報告するトップレベルの組織として存在することもあれば、より広範な開発者インフラやプラットフォーム組織内の専門チームとして機能することもあります。どちらの構造も、企業の規模、文化、既存の組織構造に応じて適切な決定を下すことで効果的です。 成功したDevExチームは、組織内のどこに位置していても、類似の使命と目標を共有しています。 以下は、よく知られた企業の実際のDevExチームのチャーターのいくつかの例です。 - Slack: 「すべてのエンジニアにとって開発体験をシームレスにする。」 - Stripe: 「Stripeでのソフトウェアエンジニアリングをより簡単にする。」 - Google: 「すべての開発者が、Googleの最高の技術とオープンソースエコシステムを活用して、迅速で高品質かつ信頼性のある体験を創出し、世界を改善することを容易にする。」 - Snyk: 「Snykでの開発を楽しめるものにする。」 言い伝えによれば、コンピュータサイエンスにおいて難しいことは二つあります。それはキャッシュの無効化と物の名前を付けること（およびオフバイワンエラー）です。開発者体験はさまざまな名前で呼ばれています。Shopifyの「Developer Acceleration」、Googleの「Engineering Productivity」、Microsoftの「Engineering Thrive」、McKinseyの「Developer Velocity」などです。業界用語にこだわるのではなく、リーダーシップに響く名前を選び、既存の組織の優先事項と一致させることが重要です。たとえば、CEOやCTOが会社の会議で「エンジニアリングの速度」を繰り返し言及している場合、チームに同様の名前を付けることで、あなたの仕事が確立されたビジネスの優先事項を直接支援していることを示すことができます。 チームの適切なサイズに関する魔法の答えはありません。障害のない作業プロセスを持ち、開発者が迅速に良い決定を下すために必要なコンテキストを持っている場合、5人の開発者のチームが10倍の規模の組織を大きく上回ることがあるのを見てきました。違いは単にチームのサイズや才能だけではなく、素晴らしい仕事を妨げる障壁を体系的に取り除くことにあります。 DevExチームのサイズに関する普遍的な公式はありませんが、以下の3つのアプローチを使うことで、正当な人員数に到達する手助けができます。 - **納品ベースのサイズ設定**: 提供する必要がある範囲とビジネスが求めるタイムラインに基づいて人員数を計算します。この方法は、特定の問題を解決するためのトップダウンの推進がある場合に最も効果的で、人員数は納品までの時間に依存します。 - **ROIベースのサイズ設定**: 予想される投資収益率に基づいて人員数を決定します。このアプローチは、利害関係者やビジネスのリーダーにとって明白でない戦略的な賭けをする際に効果的です。X人のエンジニアに投資することで、その投資の何倍ものビジネス価値が得られることを示すことができれば、人員数の要求はより説得力を持つようになります。 - **ベンチマークベースのサイズ設定**: 同業他社や同じステージの企業と比較します。組織は通常、エンジニアリングの人員の約10〜20％を中央集権的な開発者の生産性向上に割り当てますが、実際の数字は企業の成熟度、業界セクター、特定の技術的課題によって大きく異なります。場合によっては、プラットフォームやツールがより多くのレバレッジを提供するにつれて、その割合は減少します。 最も成功しているチームは、これらのアプローチを組み合わせて使用し、ベンチマークを出発点としながら、特定の納品ニーズやROIの計算に基づいて調整しています。 第42章 DevEx役割のための人材育成 成功するDevEx機能を構築するには、リソースを確保するだけでは不十分で、専門的なスキルを持った適切な人材が必要です。DevExの専門家は、技術的な専門知識、共感力、コミュニケーション能力の独自の組み合わせを求められます。従来のエンジニアリングの役割が顧客向けの機能の構築に焦点を当てているのに対し、DevExの役割は内部ユーザーに適用される製品志向のマインドセットを必要とします。最適な候補者は、多様なバックグラウンドを持つことが多く、プラットフォームエンジニアリング、フルスタック開発、開発者支援、あるいは製品管理などから来ています。効果的なDevExエンジニアやリーダーは、通常以下の特性を示します。 - **技術的な幅と深さ**: 多くの開発者を支援するために幅広い技術を理解し、プラットフォームや分散システムにおいて深い専門性を持つことが求められます。データモデルの調整や提供に特化することも重要です。 - **ユーザーへの共感**: 開発者の痛点を理解し、効果的に優先順位をつける能力。 - **データの流暢さ**: 開発者の生産性指標を測定、分析、コミュニケーションするスキル。 - **AIツールの評価**: AI開発ツールの効果を評価し、パイロット運用し、その影響を測定する方法を理解すること。 - **製品思考**: 内部ツールを顧客向け製品と同じ厳密さでアプローチすること。 - **コミュニケーションスキル**: エンジニアから経営者まで、異なる聴衆に向けて技術的な概念を翻訳する能力。 このため、DevExの取り組みに適した人材を見つけることが重要です。以下のいくつかの方法でアプローチできます。 - **内部異動**: 開発者のワークフロー改善に興味を示しているエンジニアを探し、ハッカーデイに参加したり、内部ツールの議論に貢献したりしている人を見つけます。こうした個人は、DevExにフルタイムで集中する機会を与えられると活躍することが多いです。 - **外部採用**: 外部の人材を採用する際は、プラットフォーム、ツール、または生産性エンジニアリングの経験を持つ候補者を優先します。開発者関係や支援のバックグラウンドもDevExの役割にうまく適応できます。 - **ハイブリッドアプローチ**: 多くの成功したDevExチームは、会社の文脈を理解している長期在籍の社員と、新しい視点や専門知識を持つ外部採用者を組み合わせています。 どのアプローチを取るにしても、プラットフォームやDevExチームにとっては、シニアな人材が多く、初期キャリアや中堅キャリアの人材が少ない「人材密度」が重要であることを忘れないでください。これは、彼らが責任を負うツールや技術の複雑さ、そしてビジネス全体を支えるシステムの重要性によるものです。 DevExの能力を育成すること。既存のチームメンバーや新しい採用者と共に働く場合でも、意図的な焦点を持って育成することが求められます。 + 会議への参加、トレーニングプログラム、広範なDevExコミュニティとの関わりを通じて学習の機会を創出します。 - 経験豊富なDevExの実践者とこの分野に新たに入った人との間にメンタリング関係を築きます。 - クロスファンクショナルな経験を促進するために、チームメンバーをエンジニアリング組織の異なる部門にローテーションさせることや、密接なコラボレーションを通じて、さまざまな経験を積ませましょう。ROI計算や経営陣へのプレゼンテーションにチームを関与させることで、ビジネスセンスを育成します。DevExに焦点を当てたイベント、フォーラム、オープンソースプロジェクトに参加することで、コミュニティとのつながりを築きましょう。新しいAIコーディングツールを評価し、それらの統合課題を理解し、開発者の生産性に対する実際の影響を測定することで、AI開発のトレンドを把握します。最も成功しているDevEx組織は、継続的な学習に投資しています。この分野は急速に進化しているため、新たな実践や技術に常に目を光らせることが、効果を維持するために不可欠です。DevEx専門家のためのキャリアパスを確保しましょう。DevExの才能を引き付け、維持するためには、明確なキャリアの進展機会を創出することが重要です。 + 技術的なキャリアトラック：DevExエンジニアからシニアエンジニア、さらにプリンシパル/スタッフエンジニアへと進む道で、開発者の生産性、プラットフォーム、または分散システムに特化します。AIインフラストラクチャの専門分野もますます重要になっています。 + リーダーシップトラック：チームリーダーからマネージャー、開発者体験のディレクターへと成長する道です。 + 専門分野のキャリアパス：メトリクスや計測、ワークフローの自動化、開発者教育などの分野での昇進機会を創出します。これらのパスを明確にし、各レベルでの能力定義をはっきりさせることで、チームメンバーが成長の機会を理解し、DevExが価値ある分野として組織がコミットしていることを示すことができます。DevEx機能が成熟するにつれて、才能開発への投資がますます重要になります。この仕事の専門的な性質は、意図的なスキル構築と明確なキャリアの進展を必要とし、持続可能な能力を構築します。 第43章 開発者体験を みんなの仕事にする チームが可能な限りDevExを改善できるように力を与えましょう。専任のチームがあっても、DevExの改善の余地は中央集権的なグループが対処できる範囲を大きく超えています。各チームには独自の課題があり、それはしばしばチーム自身によってのみ解決できるものです。多くの組織では、チームがリーダーシップから明示的に指示されない限り、これらの改善に時間を投資する許可や権限を持っていないという課題があります。この制限に対処することで、組織の開発者体験と生産性を大幅に向上させる能力を引き出すことができます。アトラシアンの10%の時間：チームが不満を解消する力を与える。アトラシアンのCTOラジーブ・ラジャンが会社に参加したとき、彼はおなじみの問題を発見しました。チームは何が壊れているかを知っていましたが、それを修正する力を感じていませんでした。「私たちが開発リーダーと話をしたとき、各チームには独自の問題があることがわかりましたが、それを解決する力を感じていませんでした。」 「彼らを修正するための時間を使う許可を得ていた。」 解決策はシンプルで洗練されていた。リーダーシップは開発者に対し、「日常業務を辛くしているものを改善するために、時間の10％を使うように」と明示的に指示した。 その結果は即座に現れ、測定可能だった。Confluenceチームは、48時間以内のデプロイ率を12％から31％に向上させた。Trelloチームは24,000行の不要なコードを削除した。中央サービスチームはデプロイ頻度を300％増加させた。Rajanの重要な洞察は、開発者の喜びが生産性を引き出すが、チームは機能開発ではない改善に投資するための明示的な許可が必要であるということだ。 チームが常に開発者体験（DevEx）を改善できるようにするための実証済みの方法がいくつかある。以下の実践を導入することを検討してみてほしい。 + 上級リーダーシップからの明確な時間配分ガイドラインを確立する（例：Atlassianの10％ガイドライン）。チーム内で中央のDevEx機能と連携しながら地域の改善を実施できるDevExチャンピオンを特定する。チームレベルのDevEx改善を認識し祝うための可視化メカニズムを作成し、この作業の価値を強化する。チームが自らの開発者体験を評価し、改善の機会を特定するのを助ける共有測定フレームワークを開発する。特定の問題を解決するAI開発ツールを評価するためのガイダンスを提供し、新たな摩擦点を生み出さないようにする。チームが成功した実践や共通の問題に対する解決策を交換できる知識共有チャネルを構築する。最終的な目標は完璧なDevExチームを作ることではなく、開発者体験が評価され、測定され、すべてのレベルで継続的に改善される組織を作ることだ。最も成功したDevExリーダーは、チームが構築するものだけでなく、より広範なエンジニアリング文化にどのように影響を与えるかから真の影響が生まれることを認識している。 第44章 異なる組織段階での予算確保 DevEx改善の取り組みが拡大するにつれて、その成長を支えるための資金が確保されていることを確認することが重要だ。DevEx機能を構築する上で最も持続的な課題の一つは、十分な資金を確保することだ。取るべきアプローチは、組織が成長し、DevExイニシアチブが成熟するにつれて進化するべきだ。スタートアップからエンタープライズへ：段階に応じた戦略。 - スタートアップ段階（0-50人のエンジニア）では、正式なDevEx予算は稀だ。既存のツールを活用し、直接的な予算よりも時間配分を求めることに焦点を当てる。内部ツールを製品として扱い、顧客に機能を提案するのと同様に、リーダーシップに提案する。 - 成長段階の企業（50-200人のエンジニア）では、まず控えめなツール予算から始め、次に人員を求める。初期の成功を利用してROIの根拠を構築し、DevExの価値を理解するエグゼクティブスポンサーを育成する。最初の専用DevEx予算は控えめかもしれないが、重要なのは前例を確立することだ。 - スケールアップ企業（200-1000人のエンジニア）では、対応する予算予測を伴った数年のロードマップを策定する。 業界のベンチマークを活用して、エンジニアリング予算の10〜15％を開発者体験（DevEx）に投資する正当性を示しましょう。経営陣に意味のある選択肢を提供するために、影響度に応じた段階的なオプションを提示します。企業規模（エンジニア1000人以上）では、中央予算とビジネスユニットからの貢献を組み合わせた連携型資金モデルを検討してください。最も成功している企業は、エンジニアの10〜25％をDevExの業務に充て、ビジネスユニットがDevExサービスに対して支払うチャージバックモデルを実施しています。この規模では、DevExグループはその価値と影響を示すために、ビジネスKPIとともに重要な指標を報告する必要があります。 予算を守りましょう。どの段階においても、DevExの予算は景気後退時に脆弱になります。以下の保護戦略を検討してください： - コアインフラ投資と裁量的な強化を明確に区別する。 - DevExの価値を語ることができるチーム内の支持者ネットワークを構築する。 - ROIを強調した内部ケーススタディや影響報告を定期的に公開する。 - 業界のベンチマークや同業者との比較を通じて外部の検証を活用する。 景気後退時にDevExへの投資を維持する組織は、通常、より早く回復し、より強くなります。重要なのは、これらの投資が贅沢品ではなく、レジリエンスや競争優位性の重要な推進力であることを示すデータを持つことです。 第45章 DevExを定着させる DevEx改善の取り組みは、継続的な努力がなければ停滞します。この部分では、DevExの取り組みを支えるために必要なすべてのリソースを提供しました。しかし、これはすべて、変更を定着させたい場合に従うべき5つの原則に要約できます： - 小さく始めて大きく考える。最も成功したDevExの取り組みは、正式なリソースを確保する前に価値を示すブートストラップ型の努力から始まります。 - スケールに応じてアプローチを進化させる。ブートストラップ段階で機能する戦略は、専任機能を運営したり、組織全体での採用を促進したりするために必要な戦略とは異なります。 - 中央の専門知識と分散型の所有権をバランスさせる。最も効果的なDevEx戦略は、専門的な中央チームと権限を持ったローカルチームを組み合わせています。 - ビジネスの優先事項に合わせる。DevExへの投資を、リーダーシップに響く言葉で表現し、ビジネス目標との明確な関連性を示します。 - 影響を測定し、伝える。DevExへの投資のROIを継続的に追跡し、異なる利害関係者にとって重要な言葉で成功を伝えます。 この部分で示された進行に従うことで、ブートストラップの始まりから専任機能、そして組織全体での採用へと進むことで、エンジニアリング組織とビジネスに持続的な価値を提供するDevEx改善の実践を構築できます。 第二の実践 変化を支える構造を作る 優れたDevExソリューションは、開発者が実際にそれを使用する場合にのみ意味があります。変化管理は、改善を定着させるための秘訣です。DevExの課題を特定し、解決策を優先することは、旅の半分に過ぎません。 技術的に優れた改善策であっても、効果的なチェンジマネジメントがなければ、その導入や持続可能性は難しくなります。チェンジマネジメントは技術的な作業と同じくらい重要です。改善策は、採用しやすく、繰り返し実施できるものでなければ定着しません。これはしばしば、プロセスやワークフロー、文化的な規範を再構築することを意味します。 第46章　DevExチェンジのためのフレームワーク DevExの改善は、技術的なものだけでなく、文化的な変化も伴うことがほとんどです。文化の変化は測定が難しいですが、成功には不可欠です。特に新しいツールやAI開発ツールを導入する際には、この点が重要です。例えば、チームは新しいAIアシスタントの使い方だけでなく、AIが生成したコードをいつ信頼するか、どのように効果的にレビューするか、コードの品質基準を維持する方法を学ぶ必要があります。共通の言語と目標を作ることで、採用が加速し、変化への抵抗が減ります。チームが開発者体験に関する同じ用語を理解し使用することで、努力を調整し、進捗を追跡しやすくなります。同様に、目標が明確でチーム間で共有されていると、人々は変化を受け入れやすくなります。なぜなら、それがより広い目標とどのように結びついているかを理解できるからです。これらの戦略の多くは、ステップ5で議論したステークホルダーとのコミュニケーションに基づいています。 組織変革のための実績のあるロードマップに従うことが重要です。成功するDevExの変革は予測可能なパターンに従います。ジョン・コッターの8ステップの変革リーダーシッププロセスは、40年以上の研究を経て洗練され、開発者体験の取り組みに直接適用できる組織変革のための実績のあるロードマップを提供します。コッターのフレームワークは、DevExの変革に向けた明確な道筋を示しています。 1. 緊急感を創出する。ステークホルダーにDevExの改善が待てない理由を理解させるため、摩擦のビジネスへの影響を伝えます。具体的には、悪い開発者体験が納品を遅らせ、コストを増加させ、競争上の不利を生むことを示します。 2. 指導的な連合を築く。技術的リーダーやエンジニアリングマネージャー、課題と解決策の両方を理解しているステークホルダーを含む、DevExの取り組みを指導し調整できる熱心なチャンピオンを集めます。 3. 戦略的ビジョンを形成する。技術的な改善をリーダーシップにとって重要なビジネス成果に結びつける、明確で魅力的な目標を定義します。 4. ボランティアの軍団を募る。開発者やチームがDevExの改善に積極的に参加し、単に受け取るのではなく、即座に価値を示し、有意義な貢献の機会を創出します。 5. 障害を取り除いて行動を促進する。チームがより良いプラクティスを採用するのを妨げる技術的および文化的な障害に対処します。プロセスの摩擦を排除し、ツールを改善し、チームの協力方法を変えます。 6. 短期的な勝利を生み出す。進捗や迅速な改善を祝うことで勢いを維持し、DevExの取り組みの価値を証明し、人々が困難な変化を乗り越えるためのエネルギーを与えます。 7. 加速を持続する。 初期の成功を受けて、さらなる改善を推進し、信頼性を高めてより複雑な問題やシステム的な課題に取り組むことが重要です。8. 変革を実施する。新しい実践を組織の成功に結びつけ、古い習慣よりも強固なものにするために、継続的な測定、強化、文化の進化を通じてそれを定着させます。以下の章では、DevExの変革における各ステップを実行するための実践的な戦略を提供し、一時的な改善ではなく持続的な変化を生み出す手助けをします。 第47章 チームを変革の中で支援する 変革の過程でチームを支援することは重要です。彼らこそがあなたのDevExの取り組みを成功させるか、失敗させるかの鍵を握っています。新しい技術やプロセスは、長期的には改善をもたらすことを目的としていても、常に混乱を引き起こします。チームは、これらの変化を成功裏に乗り越え、古い習慣に逆戻りしないために、特定のサポートが必要です。開発者が新しい働き方を受け入れるための実践的な方法はいくつかあります。 移行期間中に追加のサポートを提供する。ワークフローの変更は、一時的な非効率を生むことがありますが、その後に利益が現れます。この移行期間中には、専用のオフィスアワー、専門的なトレーニングセッション、文書化された移行パスを通じて追加のサポートを提供しましょう。物事がスムーズになる前に、しばらくは混乱が続く可能性があることを明確に伝えることで、チームが初期の摩擦を乗り越える手助けになります。 チーム内やグループ内にチャンピオンを作ることを検討してください。彼らは追加のトレーニングを受け、同僚が変化を乗り越える手助けをし、問題が発生したときの日常的なトラブルシューティングを行います。これは、Kotterが強調するボランティアの軍隊を動員することに合致しています。開発者が受け身ではなく、積極的に参加することが必要です。特にAI開発ツールを導入する際には、チームがプロンプトエンジニアリング、モデルの選択と使用、AI生成コードのレビュー、AI支援を既存のワークフローに統合するための新しいスキルを身につける必要があります。 AMA（Ask Me Anything）やリスニングツアーを継続して、新たに浮上する課題を特定します。チームが変化を実施する際には、計画段階では見えなかった新たな障害が現れます。定期的なリスニングセッションはフィードバックループを生み出し、問題が進捗を妨げる前に対処することを可能にします。大規模な組織でこれを展開する場合、地域のチャンピオンが定期的にAMAを開催することで、あなたのリーチを拡大し、率直なフィードバックを得るための安全な場を提供します。開発者は、他の場では表面化しない課題を信頼できる同僚と共有することがよくあります。これらの地域セッションは特に価値があり、チャンピオンはチーム固有の用語、ワークフロー、文化を理解しているため、懸念を具体的な改善策に翻訳する手助けができます。 AIツールを導入する際には、チャンピオンがチームがAI支援を使用すべきタイミングと従来のアプローチを使うべきタイミングについての質問をナビゲートする手助けをし、これらの新しいツールから最大の価値を引き出すための実践的なヒントを共有することもできます。 この反復的なアプローチは、上からの指示で変化を強いるのではなく、チームを支援することへのあなたのコミットメントを示しています。開発者やチームが改善を受け入れるための意味のあるインセンティブを作りましょう。DevExイニシアティブへの貢献を促す方法はいくつかあり、あなたの仕事や状況に適したものを活用してください。特に効果的な例として、以下のようなものがあります： + 新しいツールやプラクティスに対する興奮を生み出すために、目立つ賞品を用意したハッカソンを開催する。 + DevExの改善作業をパフォーマンス評価に結びつけ、チームが自分たちの（時には見えにくい）仕事が機能開発と同じくらい評価されていることを理解できるようにする。 + ドキュメントの修正や追加、ワークフローの摩擦を取り除くこと、地域のチャンピオンとしての貢献など、非技術的な貢献を認識する。 + 重要な進展を遂げたチームに対するリーダーシップの認識を手配する—この可視性は特に強力で、モチベーションを高めることができます。 + コード品質を維持または向上させながら生産性を向上させる効果的なAIツールの採用を認識する—これにより、責任あるAI使用に関する文化的な規範が確立されます。 第48章 組織を変革に導く 持続可能な組織変革を実現するのは簡単ではありませんが、積極的に導くことでそのプロセスを容易にすることができます。組織のリーダーシップをこの旅に導きましょう—彼らの持続的な支援がリソースを確保し、障害を取り除きます。チームが実装の詳細に集中する一方で、リーダーは変革プロセスの間にコミットメントを維持するために異なる情報と支援を必要とします。経営者やマネージャーは進捗を見たいと思い、課題を理解し、投資のリターンを期待するタイミングを知りたがります。エンジニアリングマネージャーやリーダーと定期的にコミュニケーションを取り、作業の進捗や課題について透明性を持って伝えましょう。改善は直線的な旅ではないことを明らかにし、チームが簡単に得られる成果から迅速な勝利を見た後、複雑さやスケールに直面して停滞したり後退したりすることがあるという一般的なパターンを共有し、より難しい問題を解決した後に再び改善することを示します。実験や失敗を、迅速な調整を可能にする貴重な学びの機会として位置づけましょう。この透明性は、進展が遅く感じられるときでも、学んだ教訓を伝えることで勢いを維持し、プロセスが機能していることをステークホルダーに示すというコッターの短期的な勝利の重要性と一致します。 各オーディエンスに響く言葉で状況の更新や進捗を共有しましょう。経営者は通常、価値創造、コスト削減、リスク軽減、競争優位性に関心を持っています。（この点については第III部で詳しく説明します。）開発者やエンジニアリングマネージャーは、通常、生産性の向上、革新の機会、満足度に焦点を当てています。あなたの成功を各グループにとって重要な用語に翻訳し、ステップ5で詳しく説明します。異なるオーディエンスにメッセージを調整することは、持続的な変革を促進します—コッターの最終ステップは、新しいプラクティスが一時的なイニシアティブにとどまらず、組織文化に根付くことを保証します。 ステップ3と7のメトリクスアプローチは、必要なデータとフィードバックメカニズムを提供します。短期的な成果を祝う一方で、長期的な利益を可視化しましょう。DevExの改善は、時間が経つにつれて最も大きな価値をもたらすことが多いです。ステークホルダーが即時の利益と将来のリターンの両方を理解できるように、戦略とロードマップを定期的に見直すことが重要です。主要な指標の進捗を追跡し、次に何が来るのかを強調する明確なダッシュボードやレポートを作成しましょう。このアプローチは二重の役割を果たします。今後の改善に対する期待感を生み出す一方で、今日の作業が明日の利益の基盤を築いていることを示します。大きなリターンがまだ見えていない時でも、途中での小さな成功を祝うことを忘れず、勢いを維持し、熱意を高めましょう。これらの祝賀は、コッターの加速を持続させる原則を支援します。つまり、初期の信頼性を利用して、より深い組織の変革を推進するのです。 第49章 自分を支える 困難な仕事を乗り越えるために 自分自身の持続可能性に投資しましょう。DevExの変革をリードすることは、短距離走ではなくマラソンです。重要な変化をチームや組織に導くことは、要求が高く、時には孤独な作業となることがあります。より良い開発者体験のチャンピオンとして、長期的に効果的であるためには、自分自身のエネルギーと視点を維持する必要があります。以下は、DevExの変革という困難な仕事を乗り越えるための強力な戦略です。 新しい技術や業界のトレンドについて学ぶ時間を確保しましょう。最新の情報を把握することで、将来のニーズを予測し、DevEx戦略が常に関連性を持つようにします。これは、急速に進化するAI開発の環境では特に重要で、新しいツールやベストプラクティスが頻繁に登場します。また、ビルドとバイの判断をより良く行うための情報を得ることができ、他の組織がどのようにDevExの作業を実行しているか、特にAIツールを開発ワークフローに統合しているかを把握する助けにもなります。例えば、他の組織の技術標準化ガイドラインを見ることで、自分の取り組みをインスパイアし、ゼロから始めるのではなく、短縮することができます。 定期的に研究、会議への参加、他のDevExリーダーとのつながりのための時間を確保しましょう。これはオプションではなく、効果的なリーダーシップにとって不可欠です。サポートと指導のための個人的な取締役会を作成しましょう。複雑な課題に取り組む際には、技術的なサポートと感情的なサポートの両方が必要です。アドバイス、視点、励ましを提供してくれるメンターや同僚、同様の仕事をしている人々を特定し、彼らを個人的な取締役会として活用しましょう。このネットワークは、避けられない挫折の際に特に価値があります。そして、以前に話したチャンピオンたちを忘れないでください。彼らは作業を分担し、障害を解決するだけでなく、組織全体に目と耳を持ち、他では得られない洞察を提供してくれます。この支援的な環境を築くことが重要です。 自分自身の周囲にあるエコシステムは、重要な変革をリードする際にしばしば伴う孤立を防ぎます。変革をリードすることは本質的に困難であることを忘れないでください。コッターの研究によれば、リーダーが新しい実践を制度化する前に燃え尽きてしまうと、変革の取り組みは失敗することが示されています。 自分が説くことを実践し、自分自身の持続可能なペースを維持しましょう。DevEx（開発者体験）の改善は、より持続可能なエンジニアリングの実践を生み出すことを目指しています。自分の作業負荷を慎重に管理し、進捗を振り返る時間を取ることで、これを体現してください。持続可能な働き方を示すことは、あなたが創り出そうとしている文化的変化を強化します。効果的なセルフケアは職場の境界を超えることを忘れないでください。あなたの身体的および精神的健康は、変革リーダーとしての効果に直接影響を与えます。運動や健康的な食事、心を落ち着けるための実践（瞑想や自然の中で過ごす時間など、あなたをリチャージさせるもの）に時間を作りましょう。あなたのDevExの取り組みは開発者の日常体験を向上させますが、あなた自身も同じように扱われるべきです。 自分自身の学びの旅を記録し、共有しましょう。DevExの改善の複雑さを乗り越える中で、何がうまくいき、何がうまくいかないかについての洞察を捉えましょう。これらの教訓を共有することで、他の人を助け、個々の在職期間を超えて生き続ける組織の記憶を作ります。（公開できる情報や推奨される発信先については、必ずリーダーシップやPRチームに確認してください。）この文書化は、同じような課題に直面している他の人々とつながることで、あなたの個人的なネットワークを強化することにもつながります。このプロセスは非常にやりがいのあるものです。直接的に同じ道を歩む誰かをメンターとして支援する場合でも、あなたの共有経験を発見し参照する無数の他者を間接的に助ける場合でも、知識の交換はあなた自身と広範なDevExコミュニティの両方に利益をもたらす好循環を生み出します。 技術的な課題と変革管理のニーズの両方に慎重に対処することで、あなたのDevExの取り組みは組織全体に持続的なポジティブな影響を与える可能性が高まります。自分自身のDevExリーダーシップに投資しましょう。ローズ・ナイトは、この章で述べられている個人の持続可能性戦略の模範です。複数の組織文化を乗り越えてきたDevExリーダーとして、彼女はより良い開発者体験を推進しながら自分自身を支える具体的なアプローチを開発しました。 個人の取締役会を構築すること。ローズは、彼女の小さな信頼できるネットワークを「取締役会」と呼ぶアイデアを、以前のエグゼクティブコーチから得たと述べています。彼女を本当に知り、彼女自身や彼女が置かれている状況について真実を伝えてくれる人々です。彼女は、異なる業界で同様の仕事をしている人々との関係を意図的に育んでおり、「フォースマルチプライヤー」と呼ばれる、彼女を他の人々とつなげることに積極的な人々ともつながっています。このネットワークは、彼女の目標である人々をより幸せで生産的にするための新しい視点や実践的な指導を提供します。継続的な学びと最新の情報を保つことが重要です。 ローズは定期的に学習のソースを評価し、専門的なネットワークとの会話が、単なる正式な教育よりも実践的な洞察を提供していることに気づきました。人々の経験に対する自然な好奇心は、彼女の知識を広げるだけでなく、支え合う関係を築く助けにもなっています。これらの戦略は、ローズがDevEx（開発者体験）変革という厳しい仕事に持続可能なアプローチを維持するのに役立ち、自己のサポートシステムに投資することがエンジニアリングチームに持続的な変化をもたらす能力を直接強化することを示しています。 ### 第三の実践 テクノロジーを持続可能かつ効果的にする 組織が開発者体験に投資する際、しばしば技術的な能力に焦点を当てる一方で、重要な真実を見落とします。それは、最も強力なツールは開発者が実際に使用するものであるということです。この章では、持続可能なテクノロジーを構築し、長期的な価値を提供するための三つの重要な戦略を探ります。それは、プロダクトマインドセットの採用、慎重な標準化の実施、そして技術的負債の管理です。変革的な開発者ツールと放置されたツールの違いは、単なる技術的な優秀さだけではなく、構想からメンテナンスに至るまでのライフサイクル全体に対するアプローチの慎重さにあります。内部の開発者を真の顧客として扱い、彼らのニーズを中心にデザインし、標準化と革新のバランスを取ることで、即時の問題を解決するだけでなく、時間が経っても持続可能なソリューションを生み出すことができます。 ### 第50章 プロダクトマインドセットを採用する すべての組織は時折つまずくものです。その理由は以下の通りです。組織は、開発者のニーズを真に理解せずにツールを構築し、革新を妨げる柔軟性のない標準を実施し、持続不可能な技術的負債を生むショートカットを取るため、DevExの取り組みでつまずくことがよくあります。この章では、これらの落とし穴を避け、開発者の生産性と満足度を真に向上させるテクノロジーを構築するためのフレームワークを提供します。成功したチームは、ツールを「自分たちのために構築するもの」と見なすのではなく、ユーザーのニーズと文脈分析に基づいたプロダクトマインドセットを採用します。このアプローチにはいくつかの利点があります。 - **アクセスしやすいユーザーリサーチ**: あなたの顧客（内部の開発者）は、自社で働いているため、比較的簡単に見つけて観察できます。これにより、外部の顧客の場合よりもフィードバックを収集するのがはるかに簡単になります。 - **迅速なフィードバックループ**: コミュニケーションチャネルは、外部製品に比べてより直接的でターゲットを絞ったものになり、迅速な反復が可能です。 - **明確なパートナーシップ**: 顧客との関係を簡単に築くことができ、開発者を念頭に置いたソリューションを作成し、彼らと共にパイロットを実施し、ツールを継続的に改善することができます。 DevExの改善をプロダクトマインドセットで考えることで、チームの目標とユーザーのニーズに合致した明確な価値提案と成功指標を特定することができます。 開発者ツールの成功を測る際には、外部製品で使用されるのと同じ指標を考慮することが重要です。以下のような指標を活用しましょう： - 月間アクティブユーザー（MAU）や日間アクティブユーザー（DAU）を追跡し、採用状況や定期的な利用状況を把握します。 - 開発者向けのアンケートを通じて顧客満足度（CSAT）を測定し、開発者の感情や課題を理解します。 - 初期の採用後も開発者がツールを使い続けているかを確認するために、リテンション率を監視します。 - 新しいユーザーが目標を達成するまでの時間を測定することで、価値を提供するスピードを示します。 - どの機能が最も価値を提供しているかを明らかにするために、機能の使用状況を分析します。 - AIツールの効果を測定し、どのAI開発機能が実際に開発者の生産性を向上させているのか、または新たな障害を生んでいるのかを理解します。 これらの製品中心の指標は、単なるデプロイメント数よりも深い洞察を提供し、開発者がツールを使用しているかどうかだけでなく、実際のニーズにどれだけ効果的に応えているかを理解するのに役立ちます。 注意すべき教訓：ツールファーストの考え方が失敗することもあります。2020年、ジェームズ・ルッソはBrexのプラットフォームチームにスタッフエンジニアとして参加し、SpotifyのBackstageフレームワークを用いた内部開発者ポータルという特定の解決策を考えていました。次の2年間、彼らの6人のエンジニアチームはこのポータルの開発に多くのリソースを投資しました。しかし、ソフトウェアカタログなどの一般的な機能が開発者に響かず、採用率は頑固に低いままでした。Brexの開発者の20〜30％以上が週に一度プラットフォームを訪れることはありませんでした。2022年末にリソースの制約が厳しくなると、チームは限られたリソースでより多くの価値を提供し、その価値を明示的に示すよう圧力を受けました。初めての開発者体験調査を実施した後、問題が明らかになりました。「私たちの開発者の最大の痛点は、内部開発者ポータルでは解決できないものでした。それはローカル開発の速度でした」とルッソは語ります。「この時点で、内部開発者ポータルがこの仕事に適したツールではないことが明らかになり、私たちは変更セットの反復作業のためにローカルファーストのツールを構築することに焦点を移しました。」 この話は、DevExイニシアチブにおける一般的な落とし穴を示しています。ツールの開発者は、問題を理解する前に特定の解決策に夢中になってしまうことがあります。それが内部開発者ポータルであれ、最新のAIコーディングアシスタントであれ、重要なのは常に開発者の痛点から始めることです。 第51章 製品管理の原則を活用して、より良いソリューションを構築する 製品管理の原則を使用することで、実際の問題を解決し、採用を促進し、組織に持続可能な価値を創出することができます。製品管理には、問題に基づいたユーザー中心のアプローチを確保するためのいくつかのステップが含まれ、競争環境や採用、測定可能な影響を全体的に考慮します。 1. 顧客とそのニーズを理解する。これにより、ユーザーに共感するだけでなく、彼らが直面している最大の問題を特定することができます。 異なるチームや役割の開発者と直接対話し（ステップ1）、その議論を補完するために、開発者やそのシステムから自己報告やシステムデータを収集してパターンや優先事項を特定します（ステップ3）。この情報を活用して、価値を示すソリューションを持つ製品ビジョンを定義します。 2. ステークホルダーに共感し、彼らのニーズをよりよく理解し、あなたのビジョンや進捗を伝えられるようにします（ステップ1と5）。これにより、顧客やスポンサー、あなたの仕事に影響を与えるその他の人々に役立つ成功指標を特定するために、製品ビジョンを洗練させることができます。 3. 開発者、ステークホルダー、既存のシステムデータと話をして得た情報や洞察に基づいて、DevExのロードマップを構築します（ステップ1と3）。成功の可能性を高めるための一つの方法は、迅速な成果を上げることから始めることです。これにより、価値を示し、勢いを得ることができます（ステップ2）。初期の取り組みや追加のデータ収集から得た洞察をもとに、評価基準を使用してより洗練された製品ロードマップを作成できます（ステップ4）。 4. すべての構築物において使いやすさを優先します。DevExツールを消費者向け製品のように扱い、直感的なインターフェース、明確なドキュメント、合理的なデフォルトに焦点を当てます。開発者は新しいツールを学ぶための時間が限られていることを忘れないでください。参入障壁を下げることは、採用率の向上に直結します。これは特にAI開発ツールにおいて重要で、開発者はツールの使い方だけでなく、効果的なプロンプトの作成やAI生成コードのワークフローへの統合方法も学ぶ必要があります。初期のオンボーディングと日常的な使用ケースの両方を考慮し、認知負荷を軽減する一貫したパターンを使用して設計します。 5. ユーザーや彼らが使用するワークフローソリューションと常に情報を共有し、関与するためのフィードバックループを作成します。これには、優先事項やデータのギャップに基づいた追加の計測、パイロットチームとの定期的なチェックイン、開発者調査からの継続的なフィードバックや満足度データが含まれます（ステップ3と4）。 6. 構築を続けながら学び、発見を重ねます。実験、結果の評価、継続的なデータ収集やユーザーフィードバックに基づいて反復を行います（ステップ2、3、4、7）。 7. リリース管理を忘れないでください。これには、バージョン管理や後方互換性、非推奨ポリシー、移行サポートなどの技術的ベストプラクティスが含まれます。また、主要なステークホルダーとの継続的なコミュニケーションも必要です（ステップ1と5）。このアプローチにより、あなたのDevExへの投資が実際の問題を解決し、採用され、組織に持続可能な価値を生み出すことが保証されます。次の章では、認知負荷を軽減しつつイノベーションを可能にする標準化された「ゴールデンパス」を作成する方法や、開発者体験における技術的負債を管理するための戦略について探ります。製品思考を自動化やツールにとどまらず、広く適用してください。 この章では、内部ツールやプラットフォームを製品として扱うことに焦点を当てていますが、これはDevEx（開発者エクスペリエンス）施策における製品思考の一つの応用に過ぎません。最も成功している組織は、プラットフォームツールや自動化ソリューションからデータや指標に至るまで、製品管理の原則をより広範囲にDevEx戦略全体に適用しています。製品思考は、「ツールを構築する」や「データを収集する」といった視点から「問題を解決する」ことに焦点を移し、開発者顧客との継続的な関係を築くことを重視します。これにより、一時的なプロジェクトではなく、持続的な関係が生まれます。データ駆動型のアプローチが重要である理由は、内部ユーザーである顧客から利用可能なデータが豊富にあるため、データに対しても製品思考を適用することが同様に重要です。このアプローチにより、以下のことが確保されます： - 開発者のニーズがデータ収集や計測のロードマップを導くことになり、データの可用性や一般的なフォーマット（ダッシュボードなど）に左右されない。 - ソリューションはフィードバックや変化する要件に基づいて継続的に進化し、DevExチームとステークホルダーの両方にとってより良い洞察を提供する。 - リソースは最も影響力のある領域に配分される。 - 導入状況や満足度が積極的に測定され、管理される。 ステークホルダーの問題を解決し、DevExの指標を製品として扱うことについてさらに深く探求したい方は、「進化し影響を拡大する指標を設計する」という第4の実践を参照してください。ここでは、データの収集、反復、進化に製品管理の原則を適用する方法について議論しています。 第52章 ツールの標準化を活用して効率を向上させる いつかは混乱を避けるために標準化が必要になります。開発環境における標準化は、単なる一貫性を超えた多くの利点をもたらします。開発者の認知負荷を軽減することで、ツールの設定やカスタムデプロイスクリプトの作成ではなく、製品の問題解決に集中できるようになります。プラットフォームチームが少ないツールで深い専門知識を持つようになるため、サポートもより効果的かつ効率的になります。チームが同一のワークフローやツールチェーンを使用することで、ソリューションをより簡単に共有し、情報を共有し、問題をより効果的にデバッグできるようになります。また、チームを移動する開発者の生産性も向上します。 効果的な標準化は、開発エコシステムの複数の層を考慮する必要があります。ツールの標準化（プログラミング言語の選択からCI/CDパイプライン、テストフレームワークまで）は、日常業務のための一貫した基盤を作ります。プロセスの標準化は、コードレビュー、デプロイメント、インシデント管理などの活動に対する共通の方法を確立します。また、パターンを標準化することで、再利用可能なアーキテクチャ要素（仮想マシンなど）やプロジェクト構造（PRDテンプレートなど）を作成し、組織全体でのチーム間のコラボレーションを迅速かつ容易にします。標準化は、組織内のほとんどの開発者が行う共通のタスクに焦点を当てることで、最大の価値を提供します。 開発者のワークフローをマッピングした後（ステップ1）、多くの開発者が頻繁に使用するツールなど、高トラフィックエリアに焦点を当てましょう。これらのツールは、最も高い投資対効果をもたらします。チームはしばしば誤ったターゲットを優先し、少数の開発者に影響を与える特定のプロジェクトや専門的なツールの標準化に多くの投資を行う一方で、全員が使用するコードのビルド、テスト、デプロイといった日常的なワークフローを無視してしまいます。同様に、AIコーディングツールが普及する中で、AI支援開発へのアプローチを標準化すること—AI生成コードのコードレビューの実践や、AIと従来のアプローチを使い分けるためのガイドラインを含む—は、認知負荷を軽減し、チーム間の一貫性を向上させることができます。一貫性が信頼性、セキュリティ、またはコンプライアンスに直接影響を与える領域や、認知負荷を自動化や慣れ、繰り返しによって大幅に軽減できるタスクを優先しましょう。標準化を利用してレバレッジを生み出します。ツールチェーンを標準化することで、投資を集中させることができます。標準ツールの改善は、それを使用するすべてのチームに利益をもたらします。20種類の異なるデプロイメントツールをサポートしていると、どれも特別なものにはなりませんし、リソースが分散してしまいます。覚えておいてください：標準化はコントロールやコスト削減のためではなく、最も影響を与える場所に努力を集中させることで、優れた体験を創出することが目的です。技術の標準化は期待値の管理に関するものです。効果的な標準化には、組織の一貫性とチームの柔軟性をバランスよく保つ明確なフレームワークが必要です。成功している組織のほとんどは、階層的なアプローチを採用しています。これにより、開発チームに明確さを提供し、最も重要な部分で柔軟性を持たせることができます。最も重要なのは、組織全体でサポートレベルやメンテナンスの責任について共通の期待を確立することです。 **ゴールドティア：ゴールデンパス** ゴールドティアは、組織の「ゴールデンパス」（別名「舗装された道」や「ハッピーパス」）に沿ったもので、最も一般的に使用されるツール、言語、技術が含まれます。これらの技術を選択したチームは、以下の包括的なサポートを受けることができます： + メンテナンス負担ゼロ。プラットフォームチームがすべての管理とインフラのメンテナンスを担当します。 + カスタム設定なしで「ただ動く」完全自動化されたCI/CDパイプライン。 + 最適化とスケーリングのためのDBAサポート付きの管理データベースサービス。 + 製品の可観測性のためのモニタリングとログ記録。 + セキュリティ、法務、コンプライアンスチームによる事前承認（資金は特定の組織やライセンス契約に依存する場合があります）。 このティアは、インフラの懸念を排除することで開発者の生産性を最大化し、チームが製品開発に専念できるようにします。 **シルバーティア：サポートされた代替手段** シルバーティアの技術は、組織全体で一定の規模に達していますが、主要な標準ではありません。シルバーティアの技術を選択したチームは、以下のことを期待できます： + プラットフォームチームからの部分的なサポート。 + デバッグやメンテナンスに関する一定の責任。 + 共通の問題に対する共有ソリューションへの貢献 + 監視とログ記録に関する一定の責任 + セキュリティ、法務、コンプライアンスチームによる事前承認（資金は特定の組織やライセンス契約に基づく場合があります） このレベルは、合理的なサポート効率を維持しながら、正当な技術的多様性を受け入れます。 **ブロンズレベル：承認された実験** ブロンズレベルには、承認された実験技術が含まれます。ブロンズレベルのオプションを選択するチームは以下を理解しています： + 実装とメンテナンスに対する完全な責任を負うこと - プラットフォームチームからのサポートは利用できない + これらの技術に関する組織の専門家としての役割を果たすこと + セキュリティ、法務、コンプライアンスチームによる事前承認が必要で、費用はチームが全額負担すること - すべての監視とログ記録に対する責任 - 実験が失敗した場合、承認された技術へのコード、ツールチェーン、監視の移行に責任を持つこと このレベルは、ガバナンスの枠組みを維持しながらイノベーションを可能にします。 **フレームワークを超えて** チームがどのレベルにも存在しない技術を必要とする場合、以下を提供する必要があります： - 既存のレベルが要件を満たせない理由の明確な説明 - 優れた成果や独自の能力の証拠 - 持続可能な運用計画 - セキュリティおよびコンプライアンス要件へのコミットメント - ブロンズレベルの技術に沿ったサポートと作業の明確な期待 **ゴールデンパスの力：Googleの開発者オンボーディングへのアプローチ** 新しい開発者が無限のツール選択やYAML設定をナビゲートすることを強制する代わりに、Googleは「ゴールデンパス」を提供します。これは、開発者が一般的なサービスを構築し展開するために必要なすべてを含む完全なテンプレートです。ゴールデンパスには、スケルトンコード、CI/CDパイプライン、インフラストラクチャテンプレート、監視設定などが含まれ、すべて事前に設定されて使用可能です。 Googleは、効果的なゴールデンパスの背後にある重要な原則を示しています： - 抽象化を通じて認知負荷を軽減すること - 特定のタスクに対する明確で意見のある方法を提供すること - 開発から本番環境までの完全な道筋を照らしながら、柔軟性を求める開発者にはオプションとして残すこと その利点は即座に現れます： - より迅速なオンボーディング - チーム間での一貫した基盤 - SREによるデバッグの容易さ - セキュリティポリシーの実装の簡素化 - インフラストラクチャコストの最適化 標準化の重要な要素は、技術ガバナンスと進化です。技術ガバナンスと進化は、組織の技術環境を定期的にレビューする委員会によって監視されます。このクロスファンクショナルなグループは、技術リーダー、セキュリティ専門家、ビジネス関係者を集め、フレームワークが変化するニーズに応じて反応し続けることを確保します。彼らはすべてのレベルでの使用パターンとサポート要件を評価し、現在のギャップを解決したり新しい機会を創出したりする可能性のある新興技術にも目を光らせています。 委員会は各技術に対して明確な終了基準を設定し、ツールが昇格、降格、または廃止されるべき条件を定義します。これらの基準には、採用指標、サポートの負担、セキュリティの考慮事項、戦略的整合性が含まれます。委員会は孤立して決定を下すのではなく、これらの技術を積極的に使用しているチームからのデータやフィードバックに依存し、継続的な改善の好循環を生み出します。技術が階層間で移動する必要がある場合や完全に廃止される場合、委員会は透明なタイムラインと移行経路を策定し、伝達します。この積極的なアプローチは、放棄された実験やもはや組織のニーズに応えない古い基準から技術的負債が蓄積されるのを防ぎます。おそらく最も価値のある点は、委員会がブロンズ階層の技術を使用しているチームと直接連携し、実験の成果を評価することです。実験が卓越した価値を示すと、委員会はそれらを広範な採用とサポートの増加に向けて導くことができます。逆に、実験が期待された利益をもたらさない場合、委員会はチームが既存のゴールドまたはシルバーの代替案にスムーズに移行できるよう支援し、埋没コストの誤謬が失敗したアプローチを引き延ばすのを防ぎます。このガバナンスメカニズムは、標準化を静的な命令から動的で進化するフレームワークへと変革し、安定性と革新のバランスを取ります。これにより、一貫性の利点を保持しつつ、技術の進化や変化する組織のニーズに適応することが可能になります。 アドビのポートフォリオアプローチ：スケールする技術標準化。アドビでは、ダン・ネフとケン・アンダーソンが技術の階層を、勝者と敗者を宣言するのではなく、投資ポートフォリオを管理するように扱います。「ゴールド技術は『勝者』ではありません」とネフは説明します。「それらは、最も多くのチームに最大の影響を与えるためにリソースを集中させる場所です。」 都市計画を考えてみてください：ゴールド階層には水道、下水道、電力といったユーティリティがあり、包括的なサポートがあります。ブロンズ階層？それはテントキャンプです—適切なチームには実行可能ですが、すべて自分で処理しなければなりません。チームは自分たちのニーズと能力に基づいて選択します：重要なサービスはサポートと信頼性のためにゴールド階層を選ぶかもしれませんが、実験的なチームはブロンズ階層を選ぶかもしれません。重要な洞察は、効果的な標準化は制御ではなく、組織の能力とチームのニーズに合った明確な投資レベルを作成することに関するものであるということです。標準化は銀の弾丸ではありません。一貫性は効率をもたらしますが、硬直したアプローチは開発エコシステムを凍結させる可能性があります。メインフレームやCOBOLを思い出してください。これらの技術に自らを固定し、探求の余地を持たなかった組織は、後に膨大な技術的負債に直面しました。重要なのは、標準化と実験の間で適切なバランスを見つけることです。特に今、AIがコード補完からデプロイメントまであらゆるものを変革している時期においては。良い実験は、開発チームのためのR&D部門のように機能します。それはチームに、解決策を探求するためのスペースを提供します。 既存の制限が大きな問題に発展することがあります。これは、プロダクションシステムから離れた専用のスペースで最も効果的に機能します。イノベーションデーやハッカソン、探索スプリントなど、チームが納品のプレッシャーなしに集中できる場です。目標は無意味な試行錯誤ではなく、既知の課題を解決する可能性のある技術をターゲットにした調査です。コア業務で実験を行いたい（または行う必要がある）チームには、実験を生産的に保つための基本的なガードレールを設定することをお勧めします。最初から明確な境界、タイムライン、成功基準を定義しましょう。実験中であっても、セキュリティやコンプライアンスを妥協してはいけません。学んだことは常に文書化してください。価値のあることを教えてくれる失敗した実験は、決して失敗ではありません。 大規模な言語モデルやAIツールは、なぜ実験が今重要なのかを示す完璧な例です。どのコード生成ツールが実際に開発者の生産性を向上させるのでしょうか？AIを活用したテストは、品質プロセスを改善できるのでしょうか？異なるAIツールはコードレビューの時間や品質にどのように影響するのでしょうか？どのAIコーディングワークフローが開発者の負担を軽減し、新たな摩擦を生むことなく機能するのでしょうか？ローコードプラットフォームは、将来的にメンテナンスの頭痛を引き起こすのでしょうか？これらを自分の環境で試し、開発者体験に対する実際の影響を測定しなければ、答えはわかりません。 前述の階層的なフレームワークは、実験的な技術が標準化されるための明確な道筋を提供します。アプローチがその価値を証明した場合、ガバナンス委員会はそれを階層の上位に移動させ、信頼が高まるにつれて徐々にサポートを増やすことができます。ここで重要なのは、あなたのコントロールの範囲です。組織全体に影響を及ぼすプラットフォームチームは、より広範で高い影響を持つ実験を行うことができますが、範囲が狭いチームは、特定の課題を解決しつつ標準と互換性を保つターゲットを絞った実験に集中すべきです。（コントロールの範囲についてはステップ6で触れました。） 実験の野心を実施権限に合わせて、健全で進化するエコシステムを作りましょう。 第53章 技術的負債に対処する 開発者体験のイニシアティブ すべての技術的決定にはトレードオフが伴い、時には今日の最も早い進展が明日の追加作業を生むことがあります。ウォード・カニンガムは、「技術的負債」という用語を作り出し、技術を作成する際に行ったショートカットや誤った決定から生じる累積的な負担を説明しました。マーチン・ファウラーは、私たちがよく知っている例を用いて説明しています。「私のコードベースに混乱したモジュール構造があると想像してください。新しい機能を追加する必要があります。モジュール構造が明確であれば、その機能を追加するのに4日かかりますが、この混乱した構造では6日かかります。この2日の差が負債の利息です。」 開発者体験の文脈において、技術的負債はさまざまな形で現れます。日常のワークフローにおける摩擦、複雑さや不十分なドキュメントによるコードベースの更新の難しさ、機能するために回避策が必要な古いツール、そして不一致な環境から生じる高い認知負荷などです。 十分なサポートがない自社開発のソリューション。技術的負債は、DevEx（開発者体験）イニシアチブにとって二重に重要です。既存の問題点を特定する手助けをし、新しいソリューションを構築する際に、さらなる負債を生まないようにするための指針となります。技術的負債を改善の取り組みを促進するために活用できます。開発者のタスクが技術的負債のために必要以上に時間がかかる場合、その余分な時間を見積もり、開発者がその問題に直面する頻度と彼らの完全なコストを掛け算します。この計算は、改善のための具体的なビジネスケースを提供し（第III部で説明したように）、清掃作業のように感じられるものを定量的な生産性投資に変えます。 技術的負債削減のビジネスケースを作成する。技術的負債を減らすには、組織全体の合意が必要です。負債削減は新機能よりも具体的でないように見えることが多いため、強力なビジネスケースが必要です。技術的負債の影響を測定します。現在のコストを定量化します： - 回避策や手動介入にかかる時間を追跡します。100人の開発者がそれぞれ毎日15分をデプロイメントの回避策に費やすと、年間で6,000時間以上の損失になります。 - エラー率や回復時間を測定します。パイプラインの失敗、環境のデバッグ時間、デプロイメントのロールバックなどの指標を収集します。 - 特定の摩擦点に関する開発者の満足度を調査し、隠れたコストを特定します。 負債削減の優先順位を付けます。最高のリターンをもたらす負債に焦点を当てます： - 開発者への影響の乗数。最も多くの開発者に頻繁に影響を与える問題をターゲットにします。 - ビジネスリスク。重要な運用上またはセキュリティ上の懸念を生む負債に対処します。 - 有効化の可能性。新しい機能を解放する改善を優先します。 ROIを示します。負債削減をビジネス用語で表現します： 生産性の節約を計算します。200人の開発者 × 10分の節約 × $75/時間 × 230営業日 = 年間で$575,000の生産性回復。 リスク削減を強調します。負債に対処することで、停電やセキュリティの脆弱性がどのように減少するかを定量化します。 - 有効化の価値を示します。迅速なデプロイメントや品質向上のビジネスへの影響を推定します。 - 将来の取り組みのための勢いを築くために、前後の指標を追跡し、伝えます。DevExの改善を生産性、品質、スピードといったビジネスの成果に直接結びつけることで、技術的負債を減らすことが単なる良いエンジニアリングではなく、健全なビジネス戦略であることを示します。 自社のDevExツールに技術的負債の原則を活用します。ある程度の負債は避けられませんが、ファウラーの技術的負債クワドラントは、戦略的価値とリスクが異なる負債の種類を区別するのに役立ちます。慎重なリスクと無謀なリスク、意図的な負債と偶発的な負債を区別します。「今すぐ出荷し、結果に対処しなければならない」「デザインに時間がない」「今、どうすればよかったのかがわかる」「レイヤリングとは何か？」 開発者プラットフォームにとって最も危険な側面は無謀です。長期的な影響を考慮せず、技術的妥協を理解せずに急いで生産に投入されたソリューションがこれを生み出します。 積み重なるメンテナンスの負担は、組織全体の生産性を徐々に低下させます。それに対して、慎重に計画された負債は、戦略的に良い選択肢となることがあります。たとえば、限られた機能を持つ開発者ポータルを意図的に立ち上げ、早期のフィードバックを得ることを選ぶかもしれません。その際、後で特定のコンポーネントをリファクタリングする必要があることを理解しているのです。同様に、慎重に無意識に生じる負債は、新しいソリューションを構築する際によく見られます。構築プロセスの中で、より良いアプローチを発見することがあるからです。これは、まだベストプラクティスが確立されていない未解決の問題に取り組むDevExチームにとって一般的です。急速に進化するAIツールは、その良い例です。重要な違いは意識です。トレードオフについて事前に意識的な決定を下すか、発見した後に明示的に認識し、改善の計画を立てることが求められます。DevExの取り組みにおいて技術的負債が特に重要なのは、その累積的な影響です。少し不便なデプロイメントプロセスは小さな問題に見えるかもしれませんが、何百人もの開発者が毎日それを使用する場合、小さな摩擦が大きな生産性の損失に繋がります。つまり、DevExの技術的負債は、製品コードの負債よりも高い「金利」を持つことが多いのです。しかし、それはまた、改善が大きなリターンをもたらすことを意味します。この累積的な性質は、プラットフォーム戦略の一環として技術的負債を積極的に測定し、対処することが不可欠であることを示しています。そして、覚えておいてください：負債がどのように蓄積されたかを考え続けることは、ほとんど役に立ちません。過去の決定を理解するための簡単な振り返りは有益ですが、責任を追及するのではなく、戦略的な改善にエネルギーを集中させるべきです。 **第54章 すべてをまとめる：持続可能なテクノロジーのマインドセット** 最終的に、あなたの長期的な成功は、持続可能なテクノロジーのマインドセットを採用することにかかっています。この部分では、開発者体験を持続可能にするための3つの相互に関連したアプローチを探求してきました。製品マインドセットを採用することで、実際の開発者のニーズを中心に据えた真の価値を提供するソリューションを創出します。バランスの取れた標準化を通じて、一貫性を確立しつつ、革新の余地を保ちます。そして、技術的負債を積極的に管理することで、小さな摩擦が大きな生産性の障壁に発展するのを防ぎます。これらの3つの戦略は互いに強化し合います。製品思考は、どの標準化の取り組みが最も価値をもたらすかを特定し、ガバナンスプロセスは技術的負債が標準化や開発者の満足度を損なうのを防ぎます。テクノロジーが進化するにつれて、特にAIを活用した開発ツールが登場する中で、これらの原則はますます重要になります。今、持続可能な実践を構築することで、変化するニーズに適応しながら、一貫して効率性、信頼性、満足度を提供する開発者体験を創出することができます。次の章では、これらの原則をデータとメトリクスの取り組みに拡張します。 **第4の実践 メトリクスを設計し、進化させ、影響を拡大する** ダッシュボードを作成するだけでは不十分です。あなたのデータは、ステークホルダーのために問題を解決しなければなりません。メトリクスを製品として考えてみてください。 製品と同様に、リリース時に完璧である必要はありませんが、ユーザーに役立ち、時間とともに改善されるべきです。内部の指標は顧客向けの製品とは異なりますが、製品として扱うことで重要なことに焦点を当てることができます。それは、実際の問題を解決し、価値を提供し、明確な目標を設定することです。この製品ベースのアプローチは、ステップ3で紹介した基本的な指標を、より戦略的で持続可能なものに引き上げます。このテーマについては本全体が書けるほどですが、ここでは4つの重要な柱に焦点を当てます。それは、意図的な設計、実用性、品質と信頼性の確保、そして進化の管理です。これらのトピックは以前の章でも触れましたが、これらを一緒に見ることで、どのようにシステムとして機能し、指標を改善するかが明らかになります。そして最終的には、あなたのDevExイニシアティブを向上させることにつながります。 ### ステークホルダーのためのデザイン指標 指標を有効にするためには、基本から始めましょう。それは、なぜそれが必要なのか、そして誰のためなのかということです。まず最初に、顧客を特定し、彼らが何を必要としているのかを明確にすることが重要です。彼らは内部のユーザーですが、顧客として考えることが大切です。この考え方は、指標を使って解決しようとしている核心的な問題を見失うのが容易であるため、重要です。時にはデータに溺れ、時にはデータが不足することもあります。ステップ5で戦略について話した際に触れましたが、ここでも繰り返す価値があります。あなたのステークホルダーが誰であるかを書き出してください。製品の視点で見ると、あなたのステークホルダーも顧客である可能性があります。たとえば、リーダーシップは集約されたダッシュボードからのデータを使用して意思決定を行い、開発チームは詳細なデータを使用して問題を診断し、人事部門は採用やトレーニングの決定を行うためにレポートを使用するかもしれません。指標の顧客となるグループを書き出すことで、チームからのフィードバックを得やすくなり、イニシアティブが成長する中での指針となります。顧客が何を必要としているかをただ推測するのではなく、しっかりと調査を行いましょう！開発者の摩擦点に関するデータをすでに収集しているかもしれませんが、各グループが必要とする洞察を理解するために研究を広げてください。例えば： - **開発者向け**：特定のインフラやツールに関する問題点を掘り下げます。彼らがより効率的に作業するためにどのようなデータが役立つでしょうか？ - **エンジニアリングマネージャー向け**：ボトルネックを特定し、チームの改善を導くために役立つ指標を探ります。 - **リーダー向け**：彼らの戦略的な懸念に焦点を当てます。コスト、投資収益、エンジニアリングの速度のどれにより心配しているのでしょうか？ これらの会話は、驚くべきニーズを明らかにすることがよくあります。たとえば、リーダーが純粋なスピードよりもデプロイメントの信頼性を重視していることや、マネージャーがチーム間の依存関係をより良く把握したいと考えていることが分かるかもしれません。これらの問題を念頭に置くことで、各顧客の目標を特定できます。例えば： - **リーダー**：彼らはしばしば、開発者の生産性、ビジネス価値、DevEx投資のリターンの向上を求めています。 - **エンジニアリングマネージャー**：チームの効果を高め、データから実用的な洞察を得たいと考えています。 - **開発者**： 彼らは、より生産的になり、摩擦を減らし、コーディングにもっと時間を持ち、幸せになりたいと考えています。（面白い事実：私たちの研究によると、コーディングに費やす時間は幸福度と高い相関関係があります。）これらの目標は高レベルに保ちましょう。これが複数の反復を通じてあなたを導いてくれます。リーダーシップ（彼らが資金を提供しているのですから）や他の利害関係者（彼らが改善を実現する人たちです）と定期的に確認し、全員がまだ同じ方向を向いていることを確認してください。忘れないでください：あなたも顧客の一人です。ここで多くの人が見落としがちなことがあります。それは、あなたのDevExチームも重要な顧客であるということです！利害関係者をマッピングする際には、自分自身もそのリストに加えてください。これらの指標を定期的に使用して、以下のことを行います： - 改善努力の焦点を決定する。より良い計測のための投資を正当化する。リソースの決定を行う。自分の作業の影響を追跡する。DevExの取り組みの価値を示す。実際、あなた自身が最も積極的な指標のユーザーかもしれません。結局のところ、測定できないものは改善できません。解決策に飛び込む前に、学んだことを振り返りましょう。収集したすべての問題を主要なテーマにグループ化します。すべての利害関係者のニーズが反映されていることを確認し、異なるグループが重複して抱えている問題に注意を払ってください。これらはしばしば最大の機会です。また、状況を把握することも重要です。組織内外で既に存在する指標やツールを確認してください。他のチームが似たような問題をすでに解決しているか、業界のツールを活用できるかもしれません。良い解決策がすでに存在するなら、わざわざ車輪を再発明する必要はありません。すべての目標には成功基準が必要です。これらの基準は測定可能で、あなたの目標に直接結びついている必要があります。プロジェクトやフェーズの終了を示すことができ、進捗を追跡するのに役立ちます。時には、出口基準も必要です。これを「任務完了」のチェックポイントと考えてください。ローカルビルド時間に関する具体例でこれを分解してみましょう： 高レベルの目標：開発者の摩擦を減らす。成功基準：6ヶ月以内にローカルビルド時間を20％改善する。サポート指標：ローカルビルド時間。出口基準：90％の開発者が1分未満でローカルビルドを完了する。各チームは自分たちのビルド時間を測定し、ベースラインに対する改善を追跡します。出口基準に達したら、他の焦点にシフトできます（状況が変わらない限り、またはより高い目標を設定することに決めない限り）。最後に、あなたの指標が実際のビジネスの質問に答えるものであることを確認してください。ピアレビューを改善したい場合、答えたい質問を考えてみてください。例えば、「ピアレビューのプロセスのどの部分が最も時間がかかるか？」や「ピアレビューのプロセスのどの部分に最も遅延があるか？」などです。これらは顧客が尋ねることのできる良い質問です。どちらもピアレビューの改善に役立ちますが、答えるためにはわずかに異なるデータが必要です。これらの質問は、あなたの顧客（覚えていますか？）が必要な洞察を得るのに役立ちます。第56章 指標を使用して利害関係者の問題を解決する ダッシュボードを設計する際には、一律のアプローチを避けましょう。 あなたの解決策は、異なる聴衆に合わせてさまざまな形を取ります。同じデータでも、異なるユーザーには異なるプレゼンテーションが必要です。リーダーは通常、戦略的な意思決定やリソース配分に役立つ高レベルのパターンを求めます。例えば、エンジニアリングのVPは、チーム間でリードタイムが増加していることに気づき、エンジニアリングマネージャーに改善を指示するかもしれません。一方、エンジニアリングマネージャーや開発者は、行動を促すためにより詳細な情報が必要です。そのVPがリードタイムについて尋ねると、マネージャーやそのチームは特定のコンポーネント—ビルド時間、統合テスト、リリースプロセス—を掘り下げてボトルネックを見つけ、改善計画を立てます。 利害関係者に役立つ指標を設計しましょう。LinkedInでは、マックス・カナット＝アレクサンダーと彼のチームが、異なる利害関係者に効果的にサービスを提供できる開発者体験ダッシュボードを構築しました。エンジニアリングチーム向けには、チームレベルの指標が提供され、ボトルネックを特定し、自分たちのワークフローの改善を追跡するのに役立ちました。チームは自分たちの具体的な問題点を把握し、行った変更の進捗を測定することができました。一方、リーダーシップの利害関係者には、同じ基礎データが異なるストーリーを語る形で表示され、組織全体のパターン、リソース配分のニーズ、開発者体験への投資がビジネスに与える影響を示しました。リーダーはチーム間のトレンドを把握し、改善努力の焦点をどこに置くべきかについて情報に基づいた意思決定を行うことができました。 彼らの重要な洞察は、同じ指標データが各グループの問題や意思決定のニーズに合った形で提示されることで、複数の聴衆に役立つということです。エンジニアリングチームは自分たちのワークフローに関する実行可能な詳細を求めていましたが、リーダーは組織のパターンに対する戦略的な視野を必要としていました。しかし、ダッシュボードに限定する必要はありません。あなたのDevExツールキットには以下が含まれるかもしれません： - トレンドや推奨事項を強調する定期的なレポート - チームがデータを理解し、行動に移すためのワークショップ - 指標を効果的に使用するためのトレーニングセッション - 一般的な改善パターンのためのランブック - 改善計画のためのテンプレート チームがあなたの解決策をどのように活用しているかを観察し、適応する準備をしましょう。ここに実際の例があります。例えば、チームがあなたのダッシュボードを効果的に使用できていないことに気づいたとします。その場合、単にUIを調整するのではなく、より深く掘り下げてみましょう。チームと話してみてください—彼らはデータを理解しているかもしれませんが、どのように行動に移すべきかがわからないのかもしれません。それは異なる問題です！改善計画のテンプレートを作成したり、チームが成功したアプローチを共有する「実践コミュニティ」を始めたりするなどの解決策を試すことができます。 第57章 速さは競争相手に対して相対的である DevExの成功を測る真の指標を見つけるためには、内向きだけでなく外向きにも目を向ける必要があります。競合他社（または参照企業）で開発者が仕事をするために取るステップのリストを作成し始めましょう。この文脈では、競合他社とは、同じ規模の組織で、同様の制約（例えば、高度に規制された業界や、さらに狭い焦点を持つ分野、例えば金融）や、同様の技術的特性（例えば、技術スタック、技術的負債/レガシーコードの量など）で働いている組織を指します。 場合によっては、2つの競合他社のリストを作成することがあります。一つは直接的な比較のためのもので、同じ業界に属し、あなたのDevEx（開発者体験）とおそらく似ているか、少し優れている企業を対象とします。もう一つは、目標とする比較のためのもので、あなたのDevExよりもはるかに優れている企業を含みます。これらのベンチマークは、ステークホルダーにビジネスケースを提示する際に特に価値があります。この情報をどのように得ることができるでしょうか？それはあなたの組織の外にあり、恐らく公表されていない情報です。まずは、あなたのネットワークや会社の開発者に「他の人の経験はどのようなものか？」と尋ねてみてください。この場合、詳細はそれほど重要ではありません。他の人が何をしているのか、何が可能なのかを一般的に理解することが重要です。おそらく、あなたはすでに良いアイデアを持っているでしょうが、仮定を文書化し検証することは、他の人が比較を求めたり、あなたが提唱している解決策が実現不可能だと主張したりする場合に役立つツールとなります。 業界標準に対するベンチマーキング。内部の指標は、あなたのDevExの改善に関する重要な洞察を提供しますが、外部のベンチマーキングは、戦略や目標を形成するための貴重な文脈を追加します。あなたの開発者体験が業界標準とどのように比較されるかを理解することで、適切な目標を設定し、かなり先行している部分や遅れている部分を特定するのに役立ちます。（ステップ3で、同業他社や目標とする企業のベンチマークを収集しているかもしれません。） ベンチマークの見つけ方： - DORAレポートやDevOpsの現状調査 - Stack OverflowやGitHubの開発者調査 - プラットフォームベンダーからの技術特化型レポート - 開発者体験に関するコミュニティやカンファレンス ベストプラクティス： - 同じ規模、技術スタック、業界の組織と比較する - すべてをベンチマークするのではなく、3〜5の主要な指標に焦点を当てる - ベンチマークはガイダンスとして使用し、厳格な目標とはしない - 適切な文脈を持って外部データを提示する - 目標を設定する際には、業界のリーダーとあなたの出発点の両方を考慮する もしエリートパフォーマーが毎日複数回デプロイを行っているが、あなたの業界が通常週に1回デプロイを行っている場合、週2回のデプロイを中間目標とする方が、いきなり毎日のデプロイを目指すよりも適切かもしれません。 適切な文脈でベンチマークを提示すること。業界のベンチマークをステークホルダーと共有する際には、常にベンチマークの出所、比較可能な組織、比較に影響を与える可能性のある方法論の違いについての関連情報を含めることを忘れないでください。そして、あなたの組織の独自の文脈が、DevExイニシアチブにおける「良い」とは何かを決定する際に、業界の平均よりも重要であることを忘れないでください。 自分自身の軌道が最も重要です。ベンチマークは文脈を提供する上で興味深く有用ですが、最も重要なのはあなた自身の進捗です。あなたは良くなっていますか、それとも悪くなっていますか？特にスタート時には、改善のトレンドに焦点を当てることが、業界の絶対的な数字を追いかけるよりも、より実行可能な洞察を提供し、チームのモメンタムを維持するのに役立ちます。 開発プロセスにおける摩擦点を明確に把握し、その発見を裏付けるデータを持っているあなたは、実際の改善を促進する測定システムを構築する準備が整いました。次の章では、適切な指標の選び方、信頼性と実行可能性の確保、ニーズの進化に応じた指標の適応方法について探ります。シンプルに始め、賢くスケールアップすることが重要です。 ### シンプルに始めて賢くスケールアップする 指標の導入は複雑である必要はありません。まずは、収集が容易で明確な価値を提供する指標から始めましょう。たとえば、開発者の満足度、プルリクエストのサイクルタイム、ビルド成功率、デプロイ頻度などが挙げられます。これらは一般的な出発点であり、開発者が日常的に直面する問題に簡単に関連付けられるためです。前の章の変更管理ツールと同様に、あなたの指標も継続的な改善を支えるために進化する必要があります。 始めたばかりの頃は、ダッシュボードやツールといった製品と、チームの支援やトレーニングといったサービスの両方を提供することになるでしょう。それは全く問題ありません！サービスは、チームのニーズをよりよく理解し、どの指標が最も重要かを特定するのに役立ちます。指標を設計する際には、この分け方を念頭に置いておきましょう。いくつかの指標はより良いサービスの提供に役立ち、他の指標は製品の価値を高めることに寄与します。 データではなく問題に焦点を当てる。指標を計画する際は、収集したいデータではなく、まずは問題から始めましょう。これにより、単にダッシュボードを作成することが目的になってしまう一般的な罠を避けることができます。すべての指標は、あなたのチームや顧客が直面している特定の課題を解決するものであるべきです。 指標を選ぶ際にはバランスが重要です。自動データ（プルリクエストの統計など）と人間のフィードバック（開発者のアンケートなど）を組み合わせましょう。チームと個人の両方の視点を考慮し、スピードだけでなく、品質も重要であることを忘れないでください。全体像を把握するためには、さまざまなタイプの指標が必要です。 操作されたり、意図しない結果を生む可能性のある指標には注意が必要です。典型的な例として、開発者がプルリクエストにどれだけ早く応答するかだけを追跡すると、彼らは迅速なPR応答時間を維持するために集中したコーディング時間を犠牲にするかもしれません。これは、あなたが重要だと示していることへの自然な反応です。解決策は、健全な緊張を生むバランスの取れた指標を使用することです。この場合、集中したコーディングに費やした時間も追跡します。この原則は、AI支援の開発において特に重要であり、AIツールが技術的負債を生まないように、コード生成の速度とコードレビューの質の両方を追跡したい場合があります。 ### SPACEを使って指標のバランスを取る バランスを確保するための強力な方法の一つが、Chapter 24で紹介したSPACEフレームワークです。SPACEは、以下の5つの次元にわたって指標を全体的に考える手助けをします。 - **満足度**: ツールやプロセスに対する開発者の満足度。 - **パフォーマンス**: 作業やプロセスの成果。 - **アクティビティ**: 行動や成果物の数。 - **コミュニケーションとコラボレーション**: 人々やシステムがどのように相互にコミュニケーションを取るか。 - 効率と流れ：最小限の遅延や中断で作業を行うこと。すべての次元からの指標を必要とするわけではなく、通常は3つか4つで十分です。しかし、5つすべてを考慮することで、広い視野を持ち、行き詰まったときに新しいアイデアを引き出すことができます。SPACEがコードレビューにどのように適用できるか見てみましょう： S: プルリクエストプロセスに対する開発者の満足度。 P: コードレビューの速度と品質。 A: 開発者あたりのPR数、PRあたりのレビュー数。 C: PRの議論、マージ時間。 E: PRがレビューを待っている時間。 （見込みのある）指標を評価します。まず、コストと利益のトレードオフを見てください。この指標を測定するのに、実際に多くの時間やお金をかけずにできるでしょうか？理論上は素晴らしい指標でも、実際に収集するのは難しいものがあります。たとえば、開発者の内輪（ローカル開発）に関する詳細なデータを取得するのは通常難しく高価ですが、PRデータは既存のツールを通じて簡単に入手できます。次に、データがどこにあるのか、どのように取得するのかを評価します。一部のデータはバージョン管理システムに保存されているかもしれませんし、他のデータは新しいツールや調査が必要かもしれません。たとえば、PRの指標は通常APIコールで取得できますが、開発者の満足度を理解するには定期的な調査を実施する必要があります。 最後に、選択した指標が行動を促すものであることを確認してください。意思決定に役立たない指標は単なるノイズです。「この数字が変わった場合、私たちはどうすればいいのか？」と自問してください。たとえば、AIツールの使用が増加しているが開発者の満足度が低下している場合、ツールのトレーニングや設定、使用ケースの見直しが必要かどうかを調査するための明確な計画を持っているべきです。 目標は意図的でありながら実用的であることです。小さく始め、最も効果的な指標に焦点を当て、そこから構築していきましょう。プロのヒント：この評価を利用して、計測の取り組みを賢く優先順位付けしてください。開発ライフサイクルの大部分が計測されていない場合、すべてを測定しようと何年も待つ必要はありません。開発者の調査（ステップ3のワークブックを参照）や既存のデータから始めることができます。これらは以下のように二重の役割を果たします： 改善の指針。調査でローカルビルド時間が最大の生産性の障害であることが示されれば、どこに焦点を当てるべきかがわかります。 計測の優先順位付け。ローカルビルドを優先事項として特定したら、それに関する客観的データを収集するためのツールへの投資を正当化できます。 顧客は、データを信頼しなければ、あなたの分析や推奨を信頼しません。測定における正確性と精度について話す人々をよく耳にしますが、これはDevExの指標にとって何を意味するのでしょうか？これをアーチェリーに例えて考えてみてください：正確性は的の中心を打つこと、精度は中心から外れていても同じ場所を一貫して打つことです。DevExデータにも同じことが当てはまります。ミリ秒単位で非常に精密なビルド時間の測定ができていても、常に30〜90秒ずれている場合、正確性に欠けます。 一方で、正確な測定値が多少のばらつきを持っている場合もあります。例えば、測定が秒単位でしか記録されていない場合でも、それらの平均は実際のビルド時間に近づきます。精度は、データの詳細さを反映しています。開発者が「ビルドが遅い」と指摘することが多い痛点であっても、あなたの計測手法が「1分未満」や「30分以上」といった粗い時間帯しか提供しない場合、これは正確ですが精度が低いことになります。実際の問題を特定し改善を始めることはできますが、詳細な比較はできません。ここに微妙な点があります：一貫して不正確なデータでも、時間をかけて価値のあるパターンを明らかにすることができます。エラーが安定している限り、相対的な変化やトレンドを追跡することが可能です。しかし、データがランダムに不正確である場合、信頼したり行動を起こしたりするのは難しいです。これらのトレードオフを理解することで、データが「十分良い」時とそうでない時を判断する助けになります。文書化は魅力的ではありませんが、非常に重要です。各指標がどのように計算されているか、データの出所、そしてどのような仮定をしているかを記録してください。例えば、PRのサイクルタイムの計算に週末が含まれていますか？タイムゾーンはどうですか？これらの詳細は、人々があなたの指標を使って意思決定を行う際、特に既存の指標やレポートと比較する際に重要です。異なるチームが異なる計算方法の指標を同じ名前で呼んでいる例や、同じ指標計算を指すのに異なる名前を使っている例を見つけることもあるでしょう。文書は人々が簡単に見つけられる場所に保管し、状況が変わったときには更新してください。明らかな問題を見つけるための基本的な検証プロセスを設定しましょう。疑わしいパターンをフラグする簡単な自動チェックから始めてください。指標に対して合理的な範囲を特定します。例えば、PRの完了時間は決して負の値になってはいけませんし、ビルド時間が2分から200分に突然跳ね上がることは調査が必要です。データ収集における予期しないギャップやスパイクを探してください。通常1日あたり100のデータポイントを得ているのに突然10しか得られない場合、何か問題がある可能性があります。類似のチームやプロジェクト間で指標を比較してください。チームAのビルド時間が他のすべてのチームの5倍も長い場合、実際に調査すべき問題があるか、測定が間違っている可能性があります。また、定期的な検証スケジュールを作成することも重要です。これらの指標がどれほど重要かに応じて、月次または四半期ごとに行うと良いでしょう。これらのレビュー中には、いくつかの指標をサンプリングし、それらを元のデータに遡って確認します。自動チェックが正しい問題をまだ捕捉しているかを確認してください。新たに対処すべきエッジケースがないかを探ります。問題を見つけたら（必ず見つかります）、それについて透明性を持ちましょう。何が間違っていたのか、どのようにそれを発見したのか、そしてどのように修正するつもりなのかを文書化してください。データの質の問題を隠すことほど、指標への信頼を早く失わせるものはありません。指標に対する信頼を築くために時間を投資しましょう。信頼は単にデータの質だけでなく、指標を時間をかけてどのように導入し維持するかにも関わっています。 チームを巻き込むことから始めましょう。指標の定義に関与させ、何を測定しているのかだけでなく、それが彼らの目標にとってなぜ重要なのかを全員が理解できるようにします。指標がどのように収集され、計算されるのかについては透明性を持ち、問題が発生した際には隠さないようにしましょう。生の数字だけでは全体のストーリーを語ることはほとんどありませんので、文脈を提供し、定量データとチームからの定性的フィードバックを組み合わせてください。指標の操作に注意が必要です。チームが特定の数字を達成するようプレッシャーを感じると、実際には何も改善しない方法でそれを達成しようとするかもしれません。小さく始めてフィードバックを集め、学んだことに基づいてアプローチを調整しましょう。最も重要なのは、指標に問題が示されたときにチームがどのような行動を取れるかを理解していることです。目指すべきは完璧さではなく、意思決定に信頼できる信頼性です。時には、一貫性のある「十分良い」データの方が、収集に時間がかかる完璧なデータよりも良いことがあります。ただし、「十分良い」アプローチの限界を理解し、文書化しておくことで、他の人が情報に基づいた意思決定を行えるようにすることが重要です。これらの原則—シンプルに始めること、指標のバランスを取ること、品質を確保すること—は、効果的なDevEx測定の基盤を形成します。しかし、もう一つ考慮すべき次元があります。それは、AIが開発者のワークフローを新たな指標や新しい考え方を必要とする形で再構築しているということです。これについては次の章で取り上げます。 第59章 AIが必要な指標をどのように変える（そして変えない）か AIは開発者の日常業務を変えるため、あなたの指標も変える必要があります。良いニュースは、あなたが学んだ測定の基本は依然として適用されるということです。AIツールが日常の開発作業に組み込まれるにつれて、「開発者体験を測定するための知識をすべて捨てる必要があるのか？」と疑問に思うかもしれません。短い答えは「いいえ」ですが、長い答えはもっと興味深いものです。基本は依然として重要です。SPACEフレームワークとDORA指標は依然として関連性があります。なぜなら、開発者は依然として迅速なビルド、信頼性のあるデプロイメント、良好なドキュメント、強力なコラボレーションを必要としており、AIはしばしば悪い基盤の痛みを隠すのではなく、むしろそれを増幅させるからです。フローと摩擦はどこにも消えていません。開発者は依然として集中力を必要としており、遅いパイプライン、不安定なテスト、不明確な所有権はそれを妨げます。そして、AIが開発者の行動を変える一方で、彼らの明確さ、自律性、習熟度、目的に対するニーズは変わりません。 AIを活用した開発にSPACEを適用する 第58章では、指標を5つの次元でバランスを取る方法としてSPACEフレームワークを紹介しました。このフレームワークは、AIを活用したワークフローを測定する際にも同様に価値があります。少し異なる質問をする必要がありますが、基本的な考え方は変わりません。 満足度：開発者はAIツールについてどう感じていますか？ツールは彼らの作業体験を改善していますか、それとも frustrate していますか？AIの提案の質に満足していますか？ パフォーマンス：AIの支援によって成果は改善されていますか？欠陥率、機能の完了時間、インシデントの解決までの時間を追跡しましょう。 活動：AIの使用パターンはどのようになっていますか？ モニタリング 提案の受け入れ率や、AIに委任される作業の種類、AIが最も使用される場面（テスト、文書、デバッグ）を把握します。コミュニケーション：AIはコラボレーションにどのように影響を与えるのでしょうか？コードレビューは文法からアーキテクチャにシフトしていますか？開発者は仲間ではなくAIに質問していますか？文書は改善されていますか、それとも悪化していますか？効率性：AIはどこで時間を節約し、どこでオーバーヘッドを生み出しているのでしょうか？ワークフローの変化、ルーチン作業で節約された時間、コンテキストのギャップや検証作業から生じる摩擦を測定します。第六の次元として「信頼」を考慮することも重要です。開発者はAIが生成したコード、コメント、提案をどれだけ信頼しているのでしょうか？これは、採用パターンやチームがAIツールから最終的に得られる価値に影響を与えます。AIは既存の作業を単に加速するのではなく、ワークフローを変革します。開発者は単にコードを書くのではなく、AIをレビューし、プロンプトを与え、方向性を示しています。そして、多くの人が見落とす点は、ほとんどのAIの使用は情報を生成するのではなく、情報について推論することに関わっているということです。開発者は、コードを生成するよりも、要約を作成したり、代替案を比較したり、スマートな検索を行ったり、研究を統合したりするためにAIを使用する時間を多く費やしています。これは、コーディングに費やした時間や書かれた行数を捉える既存の指標が、AIを活用した作業の大部分—プロンプトを作成し、提案をレビューし、AIの統合に基づいて意思決定を行う時間—を見逃していることを意味します。新しい指標は、新たに浮上する質問に答えるのに役立ちます。プロンプトの効率を追跡し、開発者が有用なAIの提案を得るまでに何回試行する必要があるかを測定します。検証作業の努力を測定し、AIが生成したコードをレビューし修正するのにかかる時間を把握します。これにより、AIが本当に時間を節約しているのか、それとも開発者の作業の場所をシフトさせているだけなのかが明らかになります。また、信頼の調整をモニタリングします—開発者がAIを過信している場合（バグを出す）と、過小評価している場合（正しいコードを二重チェックするのに時間を無駄にする）を比較します。これらの指標は、コミット頻度や変更行数などの従来の指標では捉えられない摩擦を明らかにします。AIの使用に関するテレメトリは、ワークフローの重要なパターンや変化を明らかにすることができます。開発者が自分で行う作業とAIエージェントに委任する作業の種類を把握することで、AIの価値がどこにあるのか、また新たなシステムの障害が明らかになるかもしれません。AIがチームのダイナミクスをどのように再形成しているかを観察することでも深い洞察が得られます：エンジニアは仲間ではなくAIに助けを求めていますか？コードレビューは文法の細かい指摘からアーキテクチャの議論にシフトしていますか？新しい開発者はAIが内部のコードベースを説明することで、より早くスピードを上げていますか？最も重要なのは、このデータを慎重に収集することです。AIの計測は通常、他の方法よりも詳細が必要です。個人を追跡するのではなく、チームレベルで集約し、何を測定しているのか、なぜそれを測定しているのかを透明にし、早期に人事や法務のパートナーと協力して明確なプライバシーの境界を設定します。目標は開発者の体験を向上させることであり、監視を行うことではありません。あなたの指標製品も適応する必要があります。AIと非AIのパフォーマンスを比較するセグメント化されたビューを作成し、AIが最も価値を追加する場所を明らかにするフィードバックループを構築します。 AIの影響を追跡する視覚化を導入しましょう。AIを活用してAIの指標を構築します。ここには興味深い皮肉があります。AIが測定すべきものを変える一方で、その測定インフラをより迅速に構築する手助けもしてくれるのです。AIコーディングアシスタントを利用して以下のことを行いましょう： - AIテレメトリを収集するためのデータパイプラインコードを生成する - ダッシュボードのプロトタイプや視覚化を作成する - プロンプトパターンや受け入れ率を分析するためのスクリプトを書く - チームレベルの指標を集約するためのデータ変換ロジックを構築する かつては数週間かかっていたカスタム開発が、今では数時間で基盤を整えることが可能です。ただし、特に重要な決定に影響を与える計測のためのインストゥルメンテーションに関しては、AI生成のコードを慎重に検証することを忘れないでください。そして、基盤やボイラープレートの構築にはAIを活用しつつ、測定戦略や解釈には人間の専門知識を集中させることが重要です。 AIを用いることで、混合手法の重要性がさらに増します。ログはAIが提案したことと受け入れられたことを示しますが、なぜそうなったのかは調査やインタビューでしかわかりません。テレメトリが開発者が認証コードに対してAIの提案の80%を拒否していることを示していても、それがAIがセキュリティの脆弱性を誤認しているからなのか、内部フレームワークを理解していないからなのか、あるいは開発者がセキュリティに関わる作業に対してAIを信頼していないからなのかを知るためには、開発者と話をする必要があります。「何」がパターンを明らかにし、「なぜ」が根本原因を明らかにし、何を修正すべきかを教えてくれます。 出力から成果へのシフトが重要になります。AIは、コードの行数が常に悪い指標であったことを痛感させますが、もっと重要なのは、私たちの指標を実際に重要なものに結びつけることを強制することです。開発者の生産性は目標ではなく、顧客価値の迅速な提供が目標です。これは、問題解決のスピード（アイデアから実働ソリューションまでの時間）、探索の幅（開発者がテストできるアプローチの数）、および認知負荷（AIが助けになるのか圧倒されるのか）を測定することを意味します。これらの成果に焦点を当てた指標は、単にコードの量ではなく、ビジネス価値に実際に影響を与えるものを示します。 その裏では、インフラも進化する必要があります—開発者のワークフローだけでなく。従来のテレメトリはAIのインタラクションループを捉えられないため、プロンプトワークフロー、完了、受け入れ/拒否イベントのための新しいインストゥルメンテーションが必要です。これらのリアルタイム指標は、振り返り分析では見逃されがちなパターンや摩擦を明らかにします。しかし、そこで止まらず、エージェントのワークフローも計測しましょう。エージェントが行うことを追跡することで、どのタスクが自動化に最適で、どのタスクが人間の判断を必要とするかがわかります。また、エージェントへの委任が開発者のシステムに対するメンタルモデルにどのように影響するかも示します。ルーチンタスクをオフロードすることで、開発者がアーキテクチャ的に考える余裕が生まれるのか、それとも物事の仕組みを理解する上での盲点を生むのかを知ることができます。 まずは、AIの視点から既存の指標を監査することから始めましょう。「この指標はまだ有効か？」と問いかけてみてください。 私たちが気にかけるべきことは何か？そして、「私たちのデータはどの重要なタスク、ワークフロー、フィードバックループを見逃しているのか？」すべてを捨て去ったり、ゼロからやり直したりする必要はありません。重要なギャップを埋め、新しい質問に答えるためのデータを追加しましょう。あなたのメトリクス戦略は、AIの導入に関してステークホルダーが尋ねるであろう質問を予測する必要があります。「AIはどこで最も価値を提供しているのか？」「品質のトレードオフは見られるのか？」「どのチームが最も恩恵を受けているのか？」あなたのメトリクスは、これらの質問に答えるべきであり、単に運用の速度に関する質問だけではありません。これらの洞察を用意しておくことで、AI導入戦略への信頼が高まり、チームがこれらのツールをどこでどのように活用するかについてより良い意思決定を行う手助けになります。要するに、AIは測定するものを変えますが、測定する理由は変わりません。あなたは依然として開発者の体験を理解し、改善しようとしているのです。SPACEフレームワークは依然として適用されます。基本的な考え方は変わらず、ただ新しい現実を捉えるための新しい手段が必要なだけです。 ### メトリクスを製品のように維持する あなたのメトリクスシステムには、継続的なケアとメンテナンスが必要です。バージョンや変更を厳密に追跡しましょう。何が変更され、なぜ変更されたのかを記録する変更ログを保管してください。メトリクスの計算方法を更新した際には、それを文書化しましょう。未来の自分（そして他の人たち）に感謝されることになります。例えば、PRレビュー時間の測定方法を変更して週末を除外する場合、それは大きな変更です—必ず記録しておきましょう！（あるいは、より良い方法として、新しいメトリクスを作成し、理解しやすい意味のある名前を付けると良いでしょう。）これにより、チームはなぜ数値が異なる可能性があるのかを理解し、メトリクスへの信頼を維持できます。バージョン管理については、次のように考えてみてください：小さな調整はマイナーバージョンのアップデート（v1.1からv1.2）を受け、大きな変更で歴史的な比較に影響を与える可能性がある場合はメジャーバージョンのアップデート（v1.0からv2.0）を行います。これにより、時間の経過とともに変更を追跡し、メトリクスが直接比較できない場合を理解しやすくなります。 所有権を明確にしましょう。誰かがこれらのメトリクスを担当する必要があります—技術的な実装と、それが提供するビジネス価値の両方です。明確な所有権がないと、メトリクスは陳腐化したり、誰も気づかないうちに壊れたりする傾向があります。メトリクスのオーナーは以下のことを行うべきです： - データの質と信頼性を監視する。 - メトリクスがチームの目標と一致しているか確認する。 - チームからの質問や懸念に対応する。 - 改善の計画と優先順位を立てる。 これは一人がすべてを行うことを意味するわけではありませんが、メトリクスシステムの健康に責任を持つ人が必要です。彼らをあなたのDevExメトリクスのプロダクトマネージャーと考えてみてください。 ### ユーザーの声に耳を傾け、進化する あなたのメトリクスは製品であることを忘れないでください。つまり、ユーザー（先ほど話したリーダー、マネージャー、開発者）からフィードバックを受け取り、それを改善に活かすことが重要です。これを行う方法のいくつかは以下の通りです： - メトリクスを使用しているチームとの定期的なチェックイン。 - メトリクスの有用性や問題点に関する調査。 - 実際に意思決定を促すメトリクスと、誰も使用しないメトリクスを観察すること。 - チームが必要としているデータが不足しているギャップを探すこと。 時には、理論上は素晴らしいと思える指標が、実際には誰の意思決定にも役立っていないことがあります。それは問題ありません—そういった指標は排除しましょう！誰も使わない数字でいっぱいのダッシュボードよりも、より価値のある指標を少数持つ方が良いのです。 LinkedInの指標が製品の成功を測る方法について考えてみましょう。以前の例に出てきたMax Kanat-Alexanderのチームを覚えていますか？彼らは異なる利害関係者に対応するダッシュボードを設計するだけでなく、自分たちの指標製品が実際に機能していることを証明する必要もありました。リーダーシップは、開発者体験ダッシュボードの成功をどのように測定しているのかを頻繁に尋ねました。さまざまなアプローチを試した結果、最も価値のある2つの指標が明らかになりました。 1つ目は「リピートエンゲージユーザー」です。これは、ある日ダッシュボードと対話し、その後再び戻ってきて対話するユーザーを含みます。もし彼らが戻ってくるなら、それは彼らが価値を得たということです。この指標では、実際の対話が必要であり、単にタブでダッシュボードを開いているだけではありません。 2つ目は「エンゲージしたチームの割合」です。彼らのダッシュボードはチームレベルの指標を示していたため、すべてのチームの中で自分たちのチームのダッシュボードを実際にクリックしたメンバーがいるチームの数を追跡しました。これは本質的に彼らの「市場浸透率」です。 これらのアプローチは、どの指標が本当に価値があるのか、ただのダッシュボードの雑音なのかを特定するのに役立ちました。 プラットフォームの変化に先手を打つことも重要です。開発環境は常に変化しています—新しいツール、更新されたプラットフォーム、異なるプロセス。あなたの指標もそれに合わせて進化する必要があります。以下に注意を払ってください： - 新しいデータソースが利用可能になること（例えば、最新のCIシステムがより良いビルド指標を持っているかもしれません）。 - チームの作業方法の変化（例えば、全員がトランクベースの開発に切り替えた場合、PR指標の更新が必要かもしれません）。 - 廃止されるツール（例えば、古いビルドシステムがなくなるときの計画はありますか？）。 ここで、プラットフォームチームとの良好な関係が非常に重要です。彼らは、今後の変更について事前に知らせてくれるので、最後の瞬間に指標を更新するために慌てる必要がなくなります。 指標の「日没」を忘れないでください。すべての指標が永遠に存在する必要はありません。指標が役に立たなくなったら、それを削除しましょう。もしかしたら、その指標が追跡していた問題は解決されたのかもしれませんし、チームは異なる課題に移行しているのかもしれません。また、指標が多すぎることは、少なすぎることと同じくらい悪いことがあります—それはチームが本当に重要なことに集中するのを難しくします。 指標を削除する前に、以下を確認してください： - 誰かがまだ意思決定のためにその指標を使用しているか。 - それが定期的な報告書やダッシュボードの一部であるか。 - コンプライアンスや比較のために履歴データを保持する必要があるか。 - 同じ目的をより良く果たす新しい指標があるか。 結論として、あなたのDevEx指標は設定して放置するものではありません。関連性と信頼性を保つためには、定期的な注意が必要です。しかし、明確な所有権、良好なフィードバックループ、進化する意欲があれば、チームが開発者体験についてより良い意思決定を行う手助けをし続けるでしょう。 最後に、DevExの改善は、これまで以上に迅速かつ正確に大きな価値を提供するための最も効果的な方法の一つです。しかし、これを実現するためには… その価値を実現するためには、今すぐにでも始める必要があります。第61章 何を待っているのですか？あなたは、開発者体験とビジネス成果を変革するために必要なすべてを手に入れています。この本を通じて、開発者体験は単に開発者を幸せにすることではないことを示してきました。それは、組織全体が価値を提供する能力を妨げる摩擦を体系的に取り除くことに関するものです。AIツールの導入でスピードを約束される一方で新たなボトルネックを生む場合や、生産性を奪うレガシーシステム、競争力を脅かす技術的負債に直面している場合でも、この本のフレームワークとツールは明確な前進の道を提供します。 開発者体験を改善することには、掛け算の効果があります。開発者体験を向上させることで、単に一つのチームの生産性を高めるだけでなく、時間とともに効果が増幅されるのです。 - 摩擦の少ない環境で働く開発者は、他の優秀な開発者を引き寄せます。 - 信頼性の高い成果を出すチームは、他のチームの模範となります。 - 優れた開発者体験を持つ組織は、市場の変化や顧客のニーズに迅速に適応できます。 - 開発システムを測定し最適化する企業は、より良い技術投資を行います。 今日行う改善は、今後数年にわたって大きな利益をもたらします。行動を起こす時は今です。ソフトウェア開発の環境はかつてない速さで変化しています。AIの時代に開発者体験をマスターする組織は、巨大な競争優位を持つことになります。それに対して、そうでない組織は、どれだけAIツールを導入しても追いつくのに苦労するでしょう。確かなことは、今日の市場で勝っている企業は、単にコードを早く出荷しているのではなく、より良いコードをより信頼性高く出荷し、変化する要件に迅速に適応できるチームを持っているということです。彼らは、人間の知性とAIの能力が相互に強化し合う開発環境を構築しています。これは偶然に起こるものではありません。リーダーであるあなたが、チームを妨げている摩擦を特定し、測定し、排除するために意図的な行動を取るときに実現します。 次のステップ。 この本が単なる書棚の上のリソースにならないようにしましょう。あなたが学んだ7ステップの方法論は効果的ですが、実践しなければ意味がありません。始め方は以下の通りです： - 今週：チームの中から一人の開発者を選び、第12章のガイドを使って30分のインタビューを行い、彼らの日々の最大のフラストレーションについて尋ねてみてください。あなたが学ぶことに驚くでしょう。 - 今月：ステップ1のワークフロー可視化ツールを使って、チームの現在の開発プロセスをマッピングします。最も時間とエネルギーを消費している上位3つの摩擦ポイントを特定してください。 - 今四半期：ステップ2から最初のクイックウィンを実施します。小さくても目に見えるもので、開発者体験に焦点を当てることの価値を示すものを選びましょう。その成功を利用して、より大きな変化への勢いを築いてください。 - 今年：7ステップのプロセスを完全に実行します。 12ヶ月の終わりまでには、開発者の生産性において測定可能な改善が見られ、何が効果的か（AIへの投資を含む）についてのデータが得られ、継続的な改善のための持続可能なシステムが整っているはずです。覚えておいてください：始めるのに許可は必要ありません。「私の組織はこれに対応できていない」や「私はこれらの変更を行う権限がない」といった意見はよく耳にしますが、真実はこうです。私たちが見てきた最も成功したDevExの変革のいくつかは、個々の貢献者やチームリーダーが同僚にインタビューを行い、ワークフローをマッピングして最大の問題を見つけることから始まりました。開発者体験を理解し改善するために、予算や肩書き、組織の命令は必要ありません。ただ始めることが大切です。開発者体験に関する専門知識を築くことは、自分自身のキャリアへの投資です。ソフトウェアがすべてのビジネスにおいてますます重要になる中、組織がコードの構築と出荷の方法を体系的に改善できるリーダーは非常に貴重です。このフレームワークを実装することで得られるスキル—データ分析からステークホルダーとのコミュニケーション、変革管理まで—は、卓越したリーダーを際立たせるスキルそのものです。影響を与えたい個々の貢献者であれ、チームの成長を助けようとするマネージャーであれ、競争優位を求めるエグゼクティブであれ、開発者体験は大きな成果を生み出すためのレバーとなります。未来は、これを正しく理解する組織に属します。私たちは転換点にいます。AIがソフトウェア開発を再構築していますが、本当に恩恵を受けるのは、人間の創造性とAIの能力がシームレスに協力する環境を作る方法を理解している組織です。彼らはフィードバックループを構築し、フローステートを最適化し、認知負荷を管理しています—それは個々の開発者だけでなく、全体の開発システムのためです。この本のフレームワークは単なる理論ではありません。数百の組織が開発者体験とビジネス結果を変革するのを助けてきた、実績のあるアプローチです。さあ、あなたの番です。チームを妨げている摩擦は自動的には消えません。あなたのAI投資を制限しているボトルネックも魔法のように解決することはありません。納品を遅らせている技術的負債も自動的には解消されません。しかし、あなたにはそれを変えるためのツールがあります。方法論があります。テンプレートやワークシートがあります。ケーススタディや例もあります。あなたの開発者は準備ができています。顧客は待っています。競争相手はじっとしていません。今日から始めましょう。あなたの未来の自分と、あなたの組織が感謝することでしょう。